Dependent Packages in Struts 1.1

["Craig R. McClanahan" <cr...@apache.org>]

As the topic comes up regularly, it strikes me that we haven't had any
formal discussions or decisions on what versions of our dependent packages
to include in Struts 1.1 final.  Most of them are probably
non-controversial, but there are a couple of interesting cases.  Let's
talk about the whole list on this mail thread.

Martin, could you make sure that the release notes include the final
version list we come up with?  Thanks in advance.

commons-beanutils -- Version 1.6.1 was just posted, and contains a
critical bugfix for BeanUtils.setProperty().

commons-collections -- The framework's dependency on this library is
pretty lightweight -- I suggest we go with the latest public release (2.1)

commons-dbcp -- There have been some bugfixes since the original 1.0
release; let's work on getting an update release of this out the door.

commons-digester -- A bugfix release (1.4.1) is just in the final stages
of being released.  That's the one we want.

commons-fileupload -- Martin just published a beta of this.  By our
standard rules, we'll need a final release before we can really use it.

commons-lang -- We inherit dependencies on this one -- the latest public
release (1.0.1) seems fine.

commons-pool -- Same situation as commons-dbcp.

commons-resources -- Since we decided to defer our conversion, I suggest
we omit this library from Struts 1.1 final.  That avoids the hassles
related to the fact that resources is still in the sandbox.

commons-validator -- As far as I can tell, the current public release
(1.0.1) is fine.  Are there any bugfixes we need to pick up in a 1.0.2?

jakarta-oro -- The latest public release (2.0.7) is stable and seems to
fit the bill.

Everything else comes from within our own workspace, and I'm assuming
we're going to use essentially the current HEAD branch plus critical bug
fixes, and continue our plan to package struts-el in the "contrib"
directory as we do today.

Craig


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

Re: Dependent Packages in Struts 1.1

["Craig R. McClanahan" <cr...@apache.org>]

Missed an important one, and it's a problem child as well.

commons-logging -- The current release is 1.0.2, but we are compile-time
dependent on a bugfix in the HEAD branch.  This will need a release as
well.

Craig



On Tue, 25 Feb 2003, Craig R. McClanahan wrote:

> Date: Tue, 25 Feb 2003 09:59:43 -0800 (PST)
> From: Craig R. McClanahan <cr...@apache.org>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> Subject: Dependent Packages in Struts 1.1
>
> As the topic comes up regularly, it strikes me that we haven't had any
> formal discussions or decisions on what versions of our dependent packages
> to include in Struts 1.1 final.  Most of them are probably
> non-controversial, but there are a couple of interesting cases.  Let's
> talk about the whole list on this mail thread.
>
> Martin, could you make sure that the release notes include the final
> version list we come up with?  Thanks in advance.
>
> commons-beanutils -- Version 1.6.1 was just posted, and contains a
> critical bugfix for BeanUtils.setProperty().
>
> commons-collections -- The framework's dependency on this library is
> pretty lightweight -- I suggest we go with the latest public release (2.1)
>
> commons-dbcp -- There have been some bugfixes since the original 1.0
> release; let's work on getting an update release of this out the door.
>
> commons-digester -- A bugfix release (1.4.1) is just in the final stages
> of being released.  That's the one we want.
>
> commons-fileupload -- Martin just published a beta of this.  By our
> standard rules, we'll need a final release before we can really use it.
>
> commons-lang -- We inherit dependencies on this one -- the latest public
> release (1.0.1) seems fine.
>
> commons-pool -- Same situation as commons-dbcp.
>
> commons-resources -- Since we decided to defer our conversion, I suggest
> we omit this library from Struts 1.1 final.  That avoids the hassles
> related to the fact that resources is still in the sandbox.
>
> commons-validator -- As far as I can tell, the current public release
> (1.0.1) is fine.  Are there any bugfixes we need to pick up in a 1.0.2?
>
> jakarta-oro -- The latest public release (2.0.7) is stable and seems to
> fit the bill.
>
> Everything else comes from within our own workspace, and I'm assuming
> we're going to use essentially the current HEAD branch plus critical bug
> fixes, and continue our plan to package struts-el in the "contrib"
> directory as we do today.
>
> Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

Re: Dependent Packages in Struts 1.1

[Robert Leland <rl...@apache.org>]

Martin Cooper wrote:
> "Craig R. McClanahan" <cr...@apache.org> wrote in message
> news:20030225094952.L97230@icarus.apache.org...
> 
>>As the topic comes up regularly, it strikes me that we haven't had any
>>formal discussions or decisions on what versions of our dependent packages
>>to include in Struts 1.1 final.  Most of them are probably
>>non-controversial, but there are a couple of interesting cases.  Let's
>>talk about the whole list on this mail thread.

>>commons-fileupload -- Martin just published a beta of this.  By our
>>standard rules, we'll need a final release before we can really use it.
> 
> 
> Yes. Since announcing the Beta, there has been an uptick in user activity,
> so there are a number of bugs that need to be addressed. Unfortunately,
> FileUpload seems to be a one man show (me) at the moment, with the original
> contributors being conspicuously absent. In addition, there has been some
> discussion about merging with another (non-Jakarta) file upload project. I
> need to get back in there and catch up.

Jon Scott Stevens suggested instead of creating a new another fileupload
package that maybe the current one could be improved on. I would vote
not to go there for 1.1, and I am sure you would rather get a 1.0 
released based on the current code, before merging with another file 
upload package.

-Rob



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

Re: Dependent Packages in Struts 1.1

[Martin Cooper <ma...@apache.org>]

"Mark Abbott" <Ma...@openwave.com> wrote in message
news:5.1.0.14.0.20030228084905.048e25e8@pop.openwave.com...
> Is it usual in Struts for a release candidate to come
> out with the final dependency versions for community testing,
> or will these be put in place for the final release only?

There isn't a "usual" way. ;-) With the Struts 1.0.x releases, there wasn't
a dependency on the Commons packages, as we have now, because everything was
in the Struts code base. It was only after 1.0 that things like BeanUtils,
Digester, etc. were split out from Struts to create new Commons packages.

That said, we haven't discussed the question you are asking for Struts 1.1.
My take on it would be that an RC2 build would include released versions of
those packages that have all of the functionality we need, but nightlies of
those that we still need updates for. It's not clear whether or not we would
have an additional RC build beyond that, just to pick up released versions
of all of our dependencies.

--
Martin Cooper


>
>    Mark




---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

Re: Dependent Packages in Struts 1.1

[Mark Abbott <Ma...@openwave.com>]

Is it usual in Struts for a release candidate to come
out with the final dependency versions for community testing, 
or will these be put in place for the final release only?

   Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

Re: Dependent Packages in Struts 1.1

[Martin Cooper <ma...@apache.org>]

I've removed Commons Resources from the build, and also from the Gump
descriptor, and updated the docs so that they no longer refer to this
component. Struts no longer has any Commons Sandbox dependencies. :-)

--
Martin Cooper


"Martin Cooper" <ma...@apache.org> wrote in message
news:b3gf9b$o01$1@main.gmane.org...
>
> "Craig R. McClanahan" <cr...@apache.org> wrote in message
> news:20030225094952.L97230@icarus.apache.org...
> > As the topic comes up regularly, it strikes me that we haven't had any
> > formal discussions or decisions on what versions of our dependent
packages
> > to include in Struts 1.1 final.  Most of them are probably
> > non-controversial, but there are a couple of interesting cases.  Let's
> > talk about the whole list on this mail thread.
> >
> > Martin, could you make sure that the release notes include the final
> > version list we come up with?  Thanks in advance.
>
> Sure.
>
> >
> > commons-beanutils -- Version 1.6.1 was just posted, and contains a
> > critical bugfix for BeanUtils.setProperty().
> >
> > commons-collections -- The framework's dependency on this library is
> > pretty lightweight -- I suggest we go with the latest public release
(2.1)
> >
> > commons-dbcp -- There have been some bugfixes since the original 1.0
> > release; let's work on getting an update release of this out the door.
> >
> > commons-digester -- A bugfix release (1.4.1) is just in the final stages
> > of being released.  That's the one we want.
> >
> > commons-fileupload -- Martin just published a beta of this.  By our
> > standard rules, we'll need a final release before we can really use it.
>
> Yes. Since announcing the Beta, there has been an uptick in user activity,
> so there are a number of bugs that need to be addressed. Unfortunately,
> FileUpload seems to be a one man show (me) at the moment, with the
original
> contributors being conspicuously absent. In addition, there has been some
> discussion about merging with another (non-Jakarta) file upload project. I
> need to get back in there and catch up.
>
> >
> > commons-lang -- We inherit dependencies on this one -- the latest public
> > release (1.0.1) seems fine.
> >
> > commons-pool -- Same situation as commons-dbcp.
> >
> > commons-resources -- Since we decided to defer our conversion, I suggest
> > we omit this library from Struts 1.1 final.  That avoids the hassles
> > related to the fact that resources is still in the sandbox.
>
> Check. I'll take it out of the build and also the Gump descriptor. I
assume
> you'll pull it out of the nightly builds?
>
> >
> > commons-validator -- As far as I can tell, the current public release
> > (1.0.1) is fine.  Are there any bugfixes we need to pick up in a 1.0.2?
>
> I believe so, yes. There are several outstanding bug reports, and most of
> them have been submitted by Struts users. ;-)
>
> >
> > jakarta-oro -- The latest public release (2.0.7) is stable and seems to
> > fit the bill.
> >
> > Everything else comes from within our own workspace, and I'm assuming
> > we're going to use essentially the current HEAD branch plus critical bug
> > fixes, and continue our plan to package struts-el in the "contrib"
> > directory as we do today.
>
> That's my working assumption too.
>
> --
> Martin Cooper
>
>
> >
> > Craig




---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

Re: Dependent Packages in Struts 1.1

[Martin Cooper <ma...@apache.org>]

"Craig R. McClanahan" <cr...@apache.org> wrote in message
news:20030225094952.L97230@icarus.apache.org...
> As the topic comes up regularly, it strikes me that we haven't had any
> formal discussions or decisions on what versions of our dependent packages
> to include in Struts 1.1 final.  Most of them are probably
> non-controversial, but there are a couple of interesting cases.  Let's
> talk about the whole list on this mail thread.
>
> Martin, could you make sure that the release notes include the final
> version list we come up with?  Thanks in advance.

Sure.

>
> commons-beanutils -- Version 1.6.1 was just posted, and contains a
> critical bugfix for BeanUtils.setProperty().
>
> commons-collections -- The framework's dependency on this library is
> pretty lightweight -- I suggest we go with the latest public release (2.1)
>
> commons-dbcp -- There have been some bugfixes since the original 1.0
> release; let's work on getting an update release of this out the door.
>
> commons-digester -- A bugfix release (1.4.1) is just in the final stages
> of being released.  That's the one we want.
>
> commons-fileupload -- Martin just published a beta of this.  By our
> standard rules, we'll need a final release before we can really use it.

Yes. Since announcing the Beta, there has been an uptick in user activity,
so there are a number of bugs that need to be addressed. Unfortunately,
FileUpload seems to be a one man show (me) at the moment, with the original
contributors being conspicuously absent. In addition, there has been some
discussion about merging with another (non-Jakarta) file upload project. I
need to get back in there and catch up.

>
> commons-lang -- We inherit dependencies on this one -- the latest public
> release (1.0.1) seems fine.
>
> commons-pool -- Same situation as commons-dbcp.
>
> commons-resources -- Since we decided to defer our conversion, I suggest
> we omit this library from Struts 1.1 final.  That avoids the hassles
> related to the fact that resources is still in the sandbox.

Check. I'll take it out of the build and also the Gump descriptor. I assume
you'll pull it out of the nightly builds?

>
> commons-validator -- As far as I can tell, the current public release
> (1.0.1) is fine.  Are there any bugfixes we need to pick up in a 1.0.2?

I believe so, yes. There are several outstanding bug reports, and most of
them have been submitted by Struts users. ;-)

>
> jakarta-oro -- The latest public release (2.0.7) is stable and seems to
> fit the bill.
>
> Everything else comes from within our own workspace, and I'm assuming
> we're going to use essentially the current HEAD branch plus critical bug
> fixes, and continue our plan to package struts-el in the "contrib"
> directory as we do today.

That's my working assumption too.

--
Martin Cooper


>
> Craig




---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org