You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Scott Eade <se...@backstagetech.com.au> on 2008/04/11 14:58:14 UTC
Re: svn commit: r647109 - in /turbine/core/branches/TURBINE_2_3_BRANCH:
pom.xml project.properties project.xml
hoffmann@apache.org wrote:
> Author: hoffmann
> Date: Fri Apr 11 03:53:39 2008
> New Revision: 647109
>
> URL: http://svn.apache.org/viewvc?rev=647109&view=rev
> Log:
> updated the dependencies so we can automatically download them from download.java.net/maven
>
> Modified:
> turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml
> turbine/core/branches/TURBINE_2_3_BRANCH/project.properties
> turbine/core/branches/TURBINE_2_3_BRANCH/project.xml
>
> Modified: turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml
> URL: http://svn.apache.org/viewvc/turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml?rev=647109&r1=647108&r2=647109&view=diff
> ==============================================================================
> --- turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml (original)
> +++ turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml Fri Apr 11 03:53:39 2008
> @@ -732,14 +740,14 @@
> <dependency>
> <groupId>javax.activation</groupId>
> <artifactId>activation</artifactId>
> - <version>1.0.2</version>
> + <version>1.1.1</version>
> <type>jar</type>
> <scope>compile</scope>
> </dependency>
> <dependency>
> <groupId>javax.mail</groupId>
> <artifactId>mail</artifactId>
> - <version>1.3.3</version>
> + <version>1.4.1</version>
> <type>jar</type>
> <scope>compile</scope>
> </dependency>
>
> Modified: turbine/core/branches/TURBINE_2_3_BRANCH/project.xml
> URL: http://svn.apache.org/viewvc/turbine/core/branches/TURBINE_2_3_BRANCH/project.xml?rev=647109&r1=647108&r2=647109&view=diff
> ==============================================================================
> --- turbine/core/branches/TURBINE_2_3_BRANCH/project.xml (original)
> +++ turbine/core/branches/TURBINE_2_3_BRANCH/project.xml Fri Apr 11 03:53:39 2008
> @@ -601,15 +611,15 @@
> <dependency>
> <groupId>javax.activation</groupId>
> <artifactId>activation</artifactId>
> - <version>1.0.2</version>
> - <url>http://java.sun.com/products/javabeans/glasgow/jaf.html</url>
> + <version>1.1.1</version>
> + <url>http://download.java.net/maven/1/javax.activation/jars</url>
> <type>jar</type>
> </dependency>
> <dependency>
> <groupId>javax.mail</groupId>
> <artifactId>mail</artifactId>
> - <version>1.3.3</version>
> - <url>http://java.sun.com/products/javamail/</url>
> + <version>1.4.1</version>
> + <url>http://download.java.net/maven/1/javax.mail/jars</url>
> <type>jar</type>
> </dependency>
> <dependency>
>
We move to these because we are are now requiring a minimum of J2SE
1.4. I know your intention is to do this so that we can avoid the
manual downloads, but if we are going to update these, why not also do:
* commons-email-1.1 (requires a very small change to VelocityHtmlEmail,
see: http://markmail.org/message/tihvveprdobvves7)
* commons-configuration-1.5
* commons-fileupload-1.2.1
* commons-io-1.4
* commons-logging-1.1.1
* commons-pool-1.4
* log4j-1.2.15
* servletaip-2.4
Seems like a waste not to take this opportunity to push these to the
latest available releases (that support J2SE 1.4), probably a bit late
in the process now though.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
AW: AW: VOTE to apply Scotts' Patch for updated Libraries
Posted by Jürgen Hoffmann <ho...@ellumination.de>.
Ok,
watch my commits later today
Kind regards
Juergen
> -----Ursprüngliche Nachricht-----
> Von: Scott Eade [mailto:seade@backstagetech.com.au]
> Gesendet: Donnerstag, 17. April 2008 09:09
> An: Turbine Developers List
> Betreff: Re: AW: VOTE to apply Scotts' Patch for updated Libraries
>
> Thomas Vandahl wrote:
> > Juergen Hoffmann wrote:
> >> One further question. I would like to get rid of the Checkstyle
> >> errors as long as they are only a missing space here, and bla schmah
> >> there. Should I do that after the Release or do this before the RC2
> >> Release?
> > I was hoping that we wouldn't need another RC2 and go from RC1 to
> > 2.3.3-release. So please do whatever you think is necessary *before*
> > cutting RC1. We want to get this out, finally.
> I totally agree with Thomas. We should aim to cut RC1, leave that for
> a
> minimal amount of time and then vote on making that the final release.
> It is necessary to cut a new set of files because the version number
> changes, but apart from that our preference would be for there to be no
> changes between rc1 and final.
>
> There probably are checkstyle errors to be fixed, but these are fairly
> low priority in terms of what we would like to achieve in the future.
> I
> would rather see us proceed towards a 2.3.3 release without worrying
> about these.
>
> Now the trunk is a different story - fix away.
>
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: AW: VOTE to apply Scotts' Patch for updated Libraries
Posted by Scott Eade <se...@backstagetech.com.au>.
Thomas Vandahl wrote:
> Juergen Hoffmann wrote:
>> One further question. I would like to get rid of the Checkstyle
>> errors as long as they are only a missing space here, and bla schmah
>> there. Should I do that after the Release or do this before the RC2
>> Release?
> I was hoping that we wouldn't need another RC2 and go from RC1 to
> 2.3.3-release. So please do whatever you think is necessary *before*
> cutting RC1. We want to get this out, finally.
I totally agree with Thomas. We should aim to cut RC1, leave that for a
minimal amount of time and then vote on making that the final release.
It is necessary to cut a new set of files because the version number
changes, but apart from that our preference would be for there to be no
changes between rc1 and final.
There probably are checkstyle errors to be fixed, but these are fairly
low priority in terms of what we would like to achieve in the future. I
would rather see us proceed towards a 2.3.3 release without worrying
about these.
Now the trunk is a different story - fix away.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: AW: VOTE to apply Scotts' Patch for updated Libraries
Posted by Thomas Vandahl <th...@tewisoft.de>.
Juergen Hoffmann wrote:
> One further question. I would like to get rid of the Checkstyle errors as long as they are only a missing space here, and bla schmah there. Should I do that after the Release or do this before the RC2 Release?
I was hoping that we wouldn't need another RC2 and go from RC1 to
2.3.3-release. So please do whatever you think is necessary *before*
cutting RC1. We want to get this out, finally.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
AW: VOTE to apply Scotts' Patch for updated Libraries
Posted by Juergen Hoffmann <ho...@apache.org>.
Hi Folks,
the Vote is over. As Scott suggested, I will not upgrade the commons-email dependencies. Since there are no objections I will apply lazy consensus and prepare the RC1 Release tomorrow.
One further question. I would like to get rid of the Checkstyle errors as long as they are only a missing space here, and bla schmah there. Should I do that after the Release or do this before the RC2 Release?
Kind regards
Juergen
> -----Ursprüngliche Nachricht-----
> Von: Jürgen Hoffmann [mailto:hoffmann@ellumination.de]
> Gesendet: Sonntag, 13. April 2008 13:34
> An: 'Turbine Developers List'
> Betreff: AW: VOTE to apply Scotts' Patch for updated Libraries
>
> Hi,
>
> So if no one is against starting with a Release Candidate until the
> deadline of the vote I will assume lazy consensus.
>
> I will update the changes.xml accordingly.
>
> Kind regards
>
> Juergen
>
> > -----Ursprüngliche Nachricht-----
> > Von: Thomas Vandahl [mailto:tv@apache.org]
> > Gesendet: Sonntag, 13. April 2008 11:48
> > An: Turbine Developers List
> > Betreff: Re: VOTE to apply Scotts' Patch for updated Libraries
> >
> > Jürgen Hoffmann wrote:
> > > Hi all,
> > >
> > > I want the patch to be applied. We have a beta release cycle
> started,
> > so we should have enough time to get all the problems sorted out that
> > the new lib versions might bring. The Vote ends on Wednesday 7 pm
> CEST.
> > >
> > > With this mail I want to extend the vote for the beta 1 release of
> > turbine 2.3.3 to the same time. I also want to volunteer as the
> release
> > manager. So if the vote passes I will apply the patch and release
> beta
> > 1 afterwards.
> > >
> > [X] +1 Update versions
> > > [ ] +0 go ahead I do not care
> > > [ ] -0 I don't care
> > > [ ] -1 The updated libraries make current 2.3.2 applications
> useless
> >
> > Actually, I'm a bit hesitant to update dependencies just because they
> > are there. I take it that when switching to Maven-2 we will be able
> to
> > state "works with commons-configuration 1.2 and up"? That would be a
> > better solution. However as things are now, it is probably the best
> > idea
> > to update the stuff.
> >
> > Please don't forget to add this fact to the changes.xml. (I usually
> > forget this...)
> >
> > Two additional remarks on the release:
> > 1. I looked at the list of changes since 2.3.2 and it is fairly long.
> > Looks like progress has indeed been made, although slowly.
> >
> > 2. As discussed with Juergen, I'd rather start with a Release
> Candidate
> > instead of a beta. I think that the state of the code justifies this.
> >
> > So Juergen, go ahead. It's good to have you back. If you have any
> > questions, feel free to ask.
> >
> > Bye, Thomas.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> > For additional commands, e-mail: dev-help@turbine.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
AW: VOTE to apply Scotts' Patch for updated Libraries
Posted by Jürgen Hoffmann <ho...@ellumination.de>.
Hi,
So if no one is against starting with a Release Candidate until the deadline of the vote I will assume lazy consensus.
I will update the changes.xml accordingly.
Kind regards
Juergen
> -----Ursprüngliche Nachricht-----
> Von: Thomas Vandahl [mailto:tv@apache.org]
> Gesendet: Sonntag, 13. April 2008 11:48
> An: Turbine Developers List
> Betreff: Re: VOTE to apply Scotts' Patch for updated Libraries
>
> Jürgen Hoffmann wrote:
> > Hi all,
> >
> > I want the patch to be applied. We have a beta release cycle started,
> so we should have enough time to get all the problems sorted out that
> the new lib versions might bring. The Vote ends on Wednesday 7 pm CEST.
> >
> > With this mail I want to extend the vote for the beta 1 release of
> turbine 2.3.3 to the same time. I also want to volunteer as the release
> manager. So if the vote passes I will apply the patch and release beta
> 1 afterwards.
> >
> [X] +1 Update versions
> > [ ] +0 go ahead I do not care
> > [ ] -0 I don't care
> > [ ] -1 The updated libraries make current 2.3.2 applications useless
>
> Actually, I'm a bit hesitant to update dependencies just because they
> are there. I take it that when switching to Maven-2 we will be able to
> state "works with commons-configuration 1.2 and up"? That would be a
> better solution. However as things are now, it is probably the best
> idea
> to update the stuff.
>
> Please don't forget to add this fact to the changes.xml. (I usually
> forget this...)
>
> Two additional remarks on the release:
> 1. I looked at the list of changes since 2.3.2 and it is fairly long.
> Looks like progress has indeed been made, although slowly.
>
> 2. As discussed with Juergen, I'd rather start with a Release Candidate
> instead of a beta. I think that the state of the code justifies this.
>
> So Juergen, go ahead. It's good to have you back. If you have any
> questions, feel free to ask.
>
> Bye, Thomas.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: VOTE to apply Scotts' Patch for updated Libraries
Posted by Thomas Vandahl <tv...@apache.org>.
Jürgen Hoffmann wrote:
> Hi all,
>
> I want the patch to be applied. We have a beta release cycle started, so we should have enough time to get all the problems sorted out that the new lib versions might bring. The Vote ends on Wednesday 7 pm CEST.
>
> With this mail I want to extend the vote for the beta 1 release of turbine 2.3.3 to the same time. I also want to volunteer as the release manager. So if the vote passes I will apply the patch and release beta 1 afterwards.
>
[X] +1 Update versions
> [ ] +0 go ahead I do not care
> [ ] -0 I don't care
> [ ] -1 The updated libraries make current 2.3.2 applications useless
Actually, I'm a bit hesitant to update dependencies just because they
are there. I take it that when switching to Maven-2 we will be able to
state "works with commons-configuration 1.2 and up"? That would be a
better solution. However as things are now, it is probably the best idea
to update the stuff.
Please don't forget to add this fact to the changes.xml. (I usually
forget this...)
Two additional remarks on the release:
1. I looked at the list of changes since 2.3.2 and it is fairly long.
Looks like progress has indeed been made, although slowly.
2. As discussed with Juergen, I'd rather start with a Release Candidate
instead of a beta. I think that the state of the code justifies this.
So Juergen, go ahead. It's good to have you back. If you have any
questions, feel free to ask.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: commons-email [was: Re: VOTE to apply Scotts' Patch for updated
Libraries]
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Scott,
I'm currently releasing commons-email-1.2 but need to cut another RC
tomorrow - if you would like to play with the last RC
Tag:
https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_2
Site:
http://people.apache.org/builds/commons/email/1.2/RC1/site/index.html
Binaries:
http://people.apache.org/builds/commons/email/1.2/RC1/staged/commons-email/commons-email/1.2/
Cheers,
Siegfried Goeschl
Scott Eade wrote:
> Siegfried,
>
> Do you happen to be in a position to push out an updated version of
> commons-email?
>
> I assume you are just rolling your own jar at present, yes?
>
> Thanks,
>
> Scott
>
> Siegfried Goeschl wrote:
>> Hi Scott,
>>
>> you literally saved my day since I run across the same issue - I
>> opened a JIRA issue
>>
>> https://issues.apache.org/jira/browse/EMAIL-77
>>
>> Thanks
>>
>> Siegfried Goeschl
>>
>>
>>
>> Scott Eade wrote:
>>> And having just tried commons-email-1.1 I would now say that
>>> commons-email should be left at 1.0. It appears that HtmlEmail and
>>> attachments are totally broken in 1.1 - for my purposes it is unusable.
>>>
>>> Running commons-email-1.0 with javax.mail-1.4.1 and activation-1.1.1
>>> (these last two being overridden in my pom from 1.4 and 1.1) seems
>>> to be working fine.
>>>
>>> Scott
>>>
>>> Scott Eade wrote:
>>>> Don't you just love having such a multitude of maven repositories!
>>>>
>>>> Here is some additional information that may influence the path we
>>>> take:
>>>>
>>>> * While javax.actvation:activation:1.1.1 is available from
>>>> http://download.java.net/maven/1 (which has been added to
>>>> maven.repo.remote in turbine's project.properties), it is not
>>>> currently available from http://download.java.net/maven/2 or any
>>>> of the other obvious m2 repositories. For maven 2 builds the
>>>> best
>>>> source would appear to be version 1.1 from the main m2
>>>> repository. For this reason we may want to go with 1.1 rather
>>>> than 1.1.1. People that want 1.1.1 will need to install it into
>>>> their local repositories manually and override the dependency in
>>>> their pom.
>>>> * javax.mail.1.4.1 is in the same boat - we may want to go with 1.4
>>>> rather than 1.4.1.
>>>> * log4j:log4j:1.2.15 adds a couple of jmx related dependencies that
>>>> are not currently available from the obvious m2 repositories
>>>> so we
>>>> may want to stick with 1.2.14.
>>>>
>>>> So the updates to the latest activation and mail versions were
>>>> prompted by the fact that these could be downloaded automatically.
>>>> I'm going to flip-flop on this and suggest we actually use the
>>>> following versions on the basis that it makes things easier for
>>>> people when using both m1 and m2:
>>>>
>>>> * javax.activation:activation-1.1
>>>> * javax.mail:mail-1.4
>>>> * log4j:log4j-1.2.14
>>>>
>>>> The other dependencies are all fine as far as availability in m2
>>>> repositories is concerned.
>>>>
>>>> Scott
>>>>
>>>> Scott Eade wrote:
>>>>> Jürgen Hoffmann wrote:
>>>>>> [X] +1 Update versions
>>>>>> [ ] +0 go ahead I do not care
>>>>>> [ ] -0 I don't care
>>>>>> [ ] -1 The updated libraries make current 2.3.2 applications useless
>>>>>>
>>>>> My main concern was that updating to these versions did not impact
>>>>> others, but since we don't do a release too often so we should
>>>>> take the opportunity to move forward when we have it. In
>>>>> particular though:
>>>>>
>>>>> * commons-email-1.1 would seem to go hand in hand with JavaMail
>>>>> 1.4,
>>>>> also see http://commons.apache.org/email/release_1_1.html which
>>>>> mentions a couple of bug fixes that seem fairly important.
>>>>> * commons-fileupload-1.2.1 contains a fix to an issue raised by
>>>>> Thomas V.
>>>>> (http://commons.apache.org/fileupload/changes-report.html) so I
>>>>> imagine he is already running a patched version of this.
>>>>>
>>>>> Usually a minor digit increase would signify a bug fix, so 1.2.0
>>>>> to 1.2.1 for fileupload would usually be addressing problems and
>>>>> hence a good thing. A point release (e.g. commons-io from 1.3.1,
>>>>> skipping 1.3.2, to 1.4) might add features but hopefully be
>>>>> backwards compatible (in most cases the version numbers we are
>>>>> moving to state binary and source compatibility). In summary, I
>>>>> prefer to take the opportunity to adopt the current versions when
>>>>> we have it, but will certainly balance this with testing.
>>>>>
>>>>> Looking at version numbers is interesting when we look at what are
>>>>> we doing - going from 2.3.2 to 2.3.3 radically understates the
>>>>> significance of the changes made. Unfortunately history has us a
>>>>> little trapped:
>>>>>
>>>>> * turbine-3, which no longer exists, is still in use by scarab,
>>>>> though it seems that occasional efforts are being made to port
>>>>> this over to the trunk. [Is anyone else out there still using
>>>>> turbine-3?]
>>>>> * the trunk is called turbine-2.4-dev - I think this is where
>>>>> we all
>>>>> really want to be, and the release being worked on now is really
>>>>> setting us up to move this ahead
>>>>> * here we are working to release 2.3.3, which without the
>>>>> historical
>>>>> baggage would clearly be worth calling 2.4
>>>>>
>>>>> I think after 2.3.3 is out of the way we should consider our
>>>>> version numbering carefully in order to get back on track. My
>>>>> suggestion would be that what we currently call 2.4-dev should
>>>>> become 4.0-dev.
>>>>>
>>>>> I am also +1 for going straight to 2.3.3-rc.
>>>>>
>>>>> My thanks to Thomas, Siegfried and Jurgen (welcome back) for
>>>>> making such great strides ahead in the last couple of weeks.
>>>>>
>>>>> Scott
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
>>>>> For additional commands, e-mail: dev-help@turbine.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
>>>> For additional commands, e-mail: dev-help@turbine.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
>>> For additional commands, e-mail: dev-help@turbine.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
>> For additional commands, e-mail: dev-help@turbine.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
commons-email [was: Re: VOTE to apply Scotts' Patch for updated Libraries]
Posted by Scott Eade <se...@backstagetech.com.au>.
Siegfried,
Do you happen to be in a position to push out an updated version of
commons-email?
I assume you are just rolling your own jar at present, yes?
Thanks,
Scott
Siegfried Goeschl wrote:
> Hi Scott,
>
> you literally saved my day since I run across the same issue - I
> opened a JIRA issue
>
> https://issues.apache.org/jira/browse/EMAIL-77
>
> Thanks
>
> Siegfried Goeschl
>
>
>
> Scott Eade wrote:
>> And having just tried commons-email-1.1 I would now say that
>> commons-email should be left at 1.0. It appears that HtmlEmail and
>> attachments are totally broken in 1.1 - for my purposes it is unusable.
>>
>> Running commons-email-1.0 with javax.mail-1.4.1 and activation-1.1.1
>> (these last two being overridden in my pom from 1.4 and 1.1) seems to
>> be working fine.
>>
>> Scott
>>
>> Scott Eade wrote:
>>> Don't you just love having such a multitude of maven repositories!
>>>
>>> Here is some additional information that may influence the path we
>>> take:
>>>
>>> * While javax.actvation:activation:1.1.1 is available from
>>> http://download.java.net/maven/1 (which has been added to
>>> maven.repo.remote in turbine's project.properties), it is not
>>> currently available from http://download.java.net/maven/2 or any
>>> of the other obvious m2 repositories. For maven 2 builds the best
>>> source would appear to be version 1.1 from the main m2
>>> repository. For this reason we may want to go with 1.1 rather
>>> than 1.1.1. People that want 1.1.1 will need to install it into
>>> their local repositories manually and override the dependency in
>>> their pom.
>>> * javax.mail.1.4.1 is in the same boat - we may want to go with 1.4
>>> rather than 1.4.1.
>>> * log4j:log4j:1.2.15 adds a couple of jmx related dependencies that
>>> are not currently available from the obvious m2 repositories so we
>>> may want to stick with 1.2.14.
>>>
>>> So the updates to the latest activation and mail versions were
>>> prompted by the fact that these could be downloaded automatically.
>>> I'm going to flip-flop on this and suggest we actually use the
>>> following versions on the basis that it makes things easier for
>>> people when using both m1 and m2:
>>>
>>> * javax.activation:activation-1.1
>>> * javax.mail:mail-1.4
>>> * log4j:log4j-1.2.14
>>>
>>> The other dependencies are all fine as far as availability in m2
>>> repositories is concerned.
>>>
>>> Scott
>>>
>>> Scott Eade wrote:
>>>> Jürgen Hoffmann wrote:
>>>>> [X] +1 Update versions
>>>>> [ ] +0 go ahead I do not care
>>>>> [ ] -0 I don't care
>>>>> [ ] -1 The updated libraries make current 2.3.2 applications useless
>>>>>
>>>> My main concern was that updating to these versions did not impact
>>>> others, but since we don't do a release too often so we should take
>>>> the opportunity to move forward when we have it. In particular
>>>> though:
>>>>
>>>> * commons-email-1.1 would seem to go hand in hand with JavaMail
>>>> 1.4,
>>>> also see http://commons.apache.org/email/release_1_1.html which
>>>> mentions a couple of bug fixes that seem fairly important.
>>>> * commons-fileupload-1.2.1 contains a fix to an issue raised by
>>>> Thomas V.
>>>> (http://commons.apache.org/fileupload/changes-report.html) so I
>>>> imagine he is already running a patched version of this.
>>>>
>>>> Usually a minor digit increase would signify a bug fix, so 1.2.0 to
>>>> 1.2.1 for fileupload would usually be addressing problems and hence
>>>> a good thing. A point release (e.g. commons-io from 1.3.1,
>>>> skipping 1.3.2, to 1.4) might add features but hopefully be
>>>> backwards compatible (in most cases the version numbers we are
>>>> moving to state binary and source compatibility). In summary, I
>>>> prefer to take the opportunity to adopt the current versions when
>>>> we have it, but will certainly balance this with testing.
>>>>
>>>> Looking at version numbers is interesting when we look at what are
>>>> we doing - going from 2.3.2 to 2.3.3 radically understates the
>>>> significance of the changes made. Unfortunately history has us a
>>>> little trapped:
>>>>
>>>> * turbine-3, which no longer exists, is still in use by scarab,
>>>> though it seems that occasional efforts are being made to port
>>>> this over to the trunk. [Is anyone else out there still using
>>>> turbine-3?]
>>>> * the trunk is called turbine-2.4-dev - I think this is where we
>>>> all
>>>> really want to be, and the release being worked on now is really
>>>> setting us up to move this ahead
>>>> * here we are working to release 2.3.3, which without the
>>>> historical
>>>> baggage would clearly be worth calling 2.4
>>>>
>>>> I think after 2.3.3 is out of the way we should consider our
>>>> version numbering carefully in order to get back on track. My
>>>> suggestion would be that what we currently call 2.4-dev should
>>>> become 4.0-dev.
>>>>
>>>> I am also +1 for going straight to 2.3.3-rc.
>>>>
>>>> My thanks to Thomas, Siegfried and Jurgen (welcome back) for making
>>>> such great strides ahead in the last couple of weeks.
>>>>
>>>> Scott
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
>>>> For additional commands, e-mail: dev-help@turbine.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
>>> For additional commands, e-mail: dev-help@turbine.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
>> For additional commands, e-mail: dev-help@turbine.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: VOTE to apply Scotts' Patch for updated Libraries
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Scott,
you literally saved my day since I run across the same issue - I opened
a JIRA issue
https://issues.apache.org/jira/browse/EMAIL-77
Thanks
Siegfried Goeschl
Scott Eade wrote:
> And having just tried commons-email-1.1 I would now say that
> commons-email should be left at 1.0. It appears that HtmlEmail and
> attachments are totally broken in 1.1 - for my purposes it is unusable.
>
> Running commons-email-1.0 with javax.mail-1.4.1 and activation-1.1.1
> (these last two being overridden in my pom from 1.4 and 1.1) seems to
> be working fine.
>
> Scott
>
> Scott Eade wrote:
>> Don't you just love having such a multitude of maven repositories!
>>
>> Here is some additional information that may influence the path we take:
>>
>> * While javax.actvation:activation:1.1.1 is available from
>> http://download.java.net/maven/1 (which has been added to
>> maven.repo.remote in turbine's project.properties), it is not
>> currently available from http://download.java.net/maven/2 or any
>> of the other obvious m2 repositories. For maven 2 builds the best
>> source would appear to be version 1.1 from the main m2
>> repository. For this reason we may want to go with 1.1 rather
>> than 1.1.1. People that want 1.1.1 will need to install it into
>> their local repositories manually and override the dependency in
>> their pom.
>> * javax.mail.1.4.1 is in the same boat - we may want to go with 1.4
>> rather than 1.4.1.
>> * log4j:log4j:1.2.15 adds a couple of jmx related dependencies that
>> are not currently available from the obvious m2 repositories so we
>> may want to stick with 1.2.14.
>>
>> So the updates to the latest activation and mail versions were
>> prompted by the fact that these could be downloaded automatically.
>> I'm going to flip-flop on this and suggest we actually use the
>> following versions on the basis that it makes things easier for
>> people when using both m1 and m2:
>>
>> * javax.activation:activation-1.1
>> * javax.mail:mail-1.4
>> * log4j:log4j-1.2.14
>>
>> The other dependencies are all fine as far as availability in m2
>> repositories is concerned.
>>
>> Scott
>>
>> Scott Eade wrote:
>>> Jürgen Hoffmann wrote:
>>>> [X] +1 Update versions
>>>> [ ] +0 go ahead I do not care
>>>> [ ] -0 I don't care
>>>> [ ] -1 The updated libraries make current 2.3.2 applications useless
>>>>
>>> My main concern was that updating to these versions did not impact
>>> others, but since we don't do a release too often so we should take
>>> the opportunity to move forward when we have it. In particular though:
>>>
>>> * commons-email-1.1 would seem to go hand in hand with JavaMail 1.4,
>>> also see http://commons.apache.org/email/release_1_1.html which
>>> mentions a couple of bug fixes that seem fairly important.
>>> * commons-fileupload-1.2.1 contains a fix to an issue raised by
>>> Thomas V.
>>> (http://commons.apache.org/fileupload/changes-report.html) so I
>>> imagine he is already running a patched version of this.
>>>
>>> Usually a minor digit increase would signify a bug fix, so 1.2.0 to
>>> 1.2.1 for fileupload would usually be addressing problems and hence
>>> a good thing. A point release (e.g. commons-io from 1.3.1, skipping
>>> 1.3.2, to 1.4) might add features but hopefully be backwards
>>> compatible (in most cases the version numbers we are moving to state
>>> binary and source compatibility). In summary, I prefer to take the
>>> opportunity to adopt the current versions when we have it, but will
>>> certainly balance this with testing.
>>>
>>> Looking at version numbers is interesting when we look at what are
>>> we doing - going from 2.3.2 to 2.3.3 radically understates the
>>> significance of the changes made. Unfortunately history has us a
>>> little trapped:
>>>
>>> * turbine-3, which no longer exists, is still in use by scarab,
>>> though it seems that occasional efforts are being made to port
>>> this over to the trunk. [Is anyone else out there still using
>>> turbine-3?]
>>> * the trunk is called turbine-2.4-dev - I think this is where we all
>>> really want to be, and the release being worked on now is really
>>> setting us up to move this ahead
>>> * here we are working to release 2.3.3, which without the historical
>>> baggage would clearly be worth calling 2.4
>>>
>>> I think after 2.3.3 is out of the way we should consider our version
>>> numbering carefully in order to get back on track. My suggestion
>>> would be that what we currently call 2.4-dev should become 4.0-dev.
>>>
>>> I am also +1 for going straight to 2.3.3-rc.
>>>
>>> My thanks to Thomas, Siegfried and Jurgen (welcome back) for making
>>> such great strides ahead in the last couple of weeks.
>>>
>>> Scott
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
>>> For additional commands, e-mail: dev-help@turbine.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
>> For additional commands, e-mail: dev-help@turbine.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: VOTE to apply Scotts' Patch for updated Libraries
Posted by Scott Eade <se...@backstagetech.com.au>.
And having just tried commons-email-1.1 I would now say that
commons-email should be left at 1.0. It appears that HtmlEmail and
attachments are totally broken in 1.1 - for my purposes it is unusable.
Running commons-email-1.0 with javax.mail-1.4.1 and activation-1.1.1
(these last two being overridden in my pom from 1.4 and 1.1) seems to be
working fine.
Scott
Scott Eade wrote:
> Don't you just love having such a multitude of maven repositories!
>
> Here is some additional information that may influence the path we take:
>
> * While javax.actvation:activation:1.1.1 is available from
> http://download.java.net/maven/1 (which has been added to
> maven.repo.remote in turbine's project.properties), it is not
> currently available from http://download.java.net/maven/2 or any
> of the other obvious m2 repositories. For maven 2 builds the best
> source would appear to be version 1.1 from the main m2
> repository. For this reason we may want to go with 1.1 rather
> than 1.1.1. People that want 1.1.1 will need to install it into
> their local repositories manually and override the dependency in
> their pom.
> * javax.mail.1.4.1 is in the same boat - we may want to go with 1.4
> rather than 1.4.1.
> * log4j:log4j:1.2.15 adds a couple of jmx related dependencies that
> are not currently available from the obvious m2 repositories so we
> may want to stick with 1.2.14.
>
> So the updates to the latest activation and mail versions were
> prompted by the fact that these could be downloaded automatically.
> I'm going to flip-flop on this and suggest we actually use the
> following versions on the basis that it makes things easier for people
> when using both m1 and m2:
>
> * javax.activation:activation-1.1
> * javax.mail:mail-1.4
> * log4j:log4j-1.2.14
>
> The other dependencies are all fine as far as availability in m2
> repositories is concerned.
>
> Scott
>
> Scott Eade wrote:
>> Jürgen Hoffmann wrote:
>>> [X] +1 Update versions
>>> [ ] +0 go ahead I do not care
>>> [ ] -0 I don't care
>>> [ ] -1 The updated libraries make current 2.3.2 applications useless
>>>
>> My main concern was that updating to these versions did not impact
>> others, but since we don't do a release too often so we should take
>> the opportunity to move forward when we have it. In particular though:
>>
>> * commons-email-1.1 would seem to go hand in hand with JavaMail 1.4,
>> also see http://commons.apache.org/email/release_1_1.html which
>> mentions a couple of bug fixes that seem fairly important.
>> * commons-fileupload-1.2.1 contains a fix to an issue raised by
>> Thomas V.
>> (http://commons.apache.org/fileupload/changes-report.html) so I
>> imagine he is already running a patched version of this.
>>
>> Usually a minor digit increase would signify a bug fix, so 1.2.0 to
>> 1.2.1 for fileupload would usually be addressing problems and hence a
>> good thing. A point release (e.g. commons-io from 1.3.1, skipping
>> 1.3.2, to 1.4) might add features but hopefully be backwards
>> compatible (in most cases the version numbers we are moving to state
>> binary and source compatibility). In summary, I prefer to take the
>> opportunity to adopt the current versions when we have it, but will
>> certainly balance this with testing.
>>
>> Looking at version numbers is interesting when we look at what are we
>> doing - going from 2.3.2 to 2.3.3 radically understates the
>> significance of the changes made. Unfortunately history has us a
>> little trapped:
>>
>> * turbine-3, which no longer exists, is still in use by scarab,
>> though it seems that occasional efforts are being made to port
>> this over to the trunk. [Is anyone else out there still using
>> turbine-3?]
>> * the trunk is called turbine-2.4-dev - I think this is where we all
>> really want to be, and the release being worked on now is really
>> setting us up to move this ahead
>> * here we are working to release 2.3.3, which without the historical
>> baggage would clearly be worth calling 2.4
>>
>> I think after 2.3.3 is out of the way we should consider our version
>> numbering carefully in order to get back on track. My suggestion
>> would be that what we currently call 2.4-dev should become 4.0-dev.
>>
>> I am also +1 for going straight to 2.3.3-rc.
>>
>> My thanks to Thomas, Siegfried and Jurgen (welcome back) for making
>> such great strides ahead in the last couple of weeks.
>>
>> Scott
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
>> For additional commands, e-mail: dev-help@turbine.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: VOTE to apply Scotts' Patch for updated Libraries
Posted by Scott Eade <se...@backstagetech.com.au>.
Don't you just love having such a multitude of maven repositories!
Here is some additional information that may influence the path we take:
* While javax.actvation:activation:1.1.1 is available from
http://download.java.net/maven/1 (which has been added to
maven.repo.remote in turbine's project.properties), it is not
currently available from http://download.java.net/maven/2 or any
of the other obvious m2 repositories. For maven 2 builds the best
source would appear to be version 1.1 from the main m2
repository. For this reason we may want to go with 1.1 rather
than 1.1.1. People that want 1.1.1 will need to install it into
their local repositories manually and override the dependency in
their pom.
* javax.mail.1.4.1 is in the same boat - we may want to go with 1.4
rather than 1.4.1.
* log4j:log4j:1.2.15 adds a couple of jmx related dependencies that
are not currently available from the obvious m2 repositories so we
may want to stick with 1.2.14.
So the updates to the latest activation and mail versions were prompted
by the fact that these could be downloaded automatically. I'm going to
flip-flop on this and suggest we actually use the following versions on
the basis that it makes things easier for people when using both m1 and m2:
* javax.activation:activation-1.1
* javax.mail:mail-1.4
* log4j:log4j-1.2.14
The other dependencies are all fine as far as availability in m2
repositories is concerned.
Scott
Scott Eade wrote:
> Jürgen Hoffmann wrote:
>> [X] +1 Update versions
>> [ ] +0 go ahead I do not care
>> [ ] -0 I don't care
>> [ ] -1 The updated libraries make current 2.3.2 applications useless
>>
> My main concern was that updating to these versions did not impact
> others, but since we don't do a release too often so we should take
> the opportunity to move forward when we have it. In particular though:
>
> * commons-email-1.1 would seem to go hand in hand with JavaMail 1.4,
> also see http://commons.apache.org/email/release_1_1.html which
> mentions a couple of bug fixes that seem fairly important.
> * commons-fileupload-1.2.1 contains a fix to an issue raised by
> Thomas V.
> (http://commons.apache.org/fileupload/changes-report.html) so I
> imagine he is already running a patched version of this.
>
> Usually a minor digit increase would signify a bug fix, so 1.2.0 to
> 1.2.1 for fileupload would usually be addressing problems and hence a
> good thing. A point release (e.g. commons-io from 1.3.1, skipping
> 1.3.2, to 1.4) might add features but hopefully be backwards
> compatible (in most cases the version numbers we are moving to state
> binary and source compatibility). In summary, I prefer to take the
> opportunity to adopt the current versions when we have it, but will
> certainly balance this with testing.
>
> Looking at version numbers is interesting when we look at what are we
> doing - going from 2.3.2 to 2.3.3 radically understates the
> significance of the changes made. Unfortunately history has us a
> little trapped:
>
> * turbine-3, which no longer exists, is still in use by scarab,
> though it seems that occasional efforts are being made to port
> this over to the trunk. [Is anyone else out there still using
> turbine-3?]
> * the trunk is called turbine-2.4-dev - I think this is where we all
> really want to be, and the release being worked on now is really
> setting us up to move this ahead
> * here we are working to release 2.3.3, which without the historical
> baggage would clearly be worth calling 2.4
>
> I think after 2.3.3 is out of the way we should consider our version
> numbering carefully in order to get back on track. My suggestion
> would be that what we currently call 2.4-dev should become 4.0-dev.
>
> I am also +1 for going straight to 2.3.3-rc.
>
> My thanks to Thomas, Siegfried and Jurgen (welcome back) for making
> such great strides ahead in the last couple of weeks.
>
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: VOTE to apply Scotts' Patch for updated Libraries
Posted by Scott Eade <se...@backstagetech.com.au>.
Jürgen Hoffmann wrote:
> [X] +1 Update versions
> [ ] +0 go ahead I do not care
> [ ] -0 I don't care
> [ ] -1 The updated libraries make current 2.3.2 applications useless
>
My main concern was that updating to these versions did not impact
others, but since we don't do a release too often so we should take the
opportunity to move forward when we have it. In particular though:
* commons-email-1.1 would seem to go hand in hand with JavaMail 1.4,
also see http://commons.apache.org/email/release_1_1.html which
mentions a couple of bug fixes that seem fairly important.
* commons-fileupload-1.2.1 contains a fix to an issue raised by
Thomas V.
(http://commons.apache.org/fileupload/changes-report.html) so I
imagine he is already running a patched version of this.
Usually a minor digit increase would signify a bug fix, so 1.2.0 to
1.2.1 for fileupload would usually be addressing problems and hence a
good thing. A point release (e.g. commons-io from 1.3.1, skipping
1.3.2, to 1.4) might add features but hopefully be backwards compatible
(in most cases the version numbers we are moving to state binary and
source compatibility). In summary, I prefer to take the opportunity to
adopt the current versions when we have it, but will certainly balance
this with testing.
Looking at version numbers is interesting when we look at what are we
doing - going from 2.3.2 to 2.3.3 radically understates the significance
of the changes made. Unfortunately history has us a little trapped:
* turbine-3, which no longer exists, is still in use by scarab,
though it seems that occasional efforts are being made to port
this over to the trunk. [Is anyone else out there still using
turbine-3?]
* the trunk is called turbine-2.4-dev - I think this is where we all
really want to be, and the release being worked on now is really
setting us up to move this ahead
* here we are working to release 2.3.3, which without the historical
baggage would clearly be worth calling 2.4
I think after 2.3.3 is out of the way we should consider our version
numbering carefully in order to get back on track. My suggestion would
be that what we currently call 2.4-dev should become 4.0-dev.
I am also +1 for going straight to 2.3.3-rc.
My thanks to Thomas, Siegfried and Jurgen (welcome back) for making such
great strides ahead in the last couple of weeks.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
VOTE to apply Scotts' Patch for updated Libraries
Posted by Jürgen Hoffmann <ho...@ellumination.de>.
Hi all,
I want the patch to be applied. We have a beta release cycle started, so we should have enough time to get all the problems sorted out that the new lib versions might bring. The Vote ends on Wednesday 7 pm CEST.
With this mail I want to extend the vote for the beta 1 release of turbine 2.3.3 to the same time. I also want to volunteer as the release manager. So if the vote passes I will apply the patch and release beta 1 afterwards.
[ ] +1 Update versions
[ ] +0 go ahead I do not care
[ ] -0 I don't care
[ ] -1 The updated libraries make current 2.3.2 applications useless
Kind regards
Juergen
-----Ursprüngliche Nachricht-----
Von: Scott Eade [mailto:seade@backstagetech.com.au]
Gesendet: Samstag, 12. April 2008 17:07
An: Turbine Developers List
Betreff: Re: AW: svn commit: r647109 - in /turbine/core/branches/TURBINE_2_3_BRANCH: pom.xml project.properties project.xml
Just in case we decide to proceed, here is the patch.
I have successfully built a jar here with this patch applied.
Scott
Index: S:/eclipse-workspace/turbine-2_3/pom.xml
===================================================================
--- S:/eclipse-workspace/turbine-2_3/pom.xml (revision 647191)
+++ S:/eclipse-workspace/turbine-2_3/pom.xml (working copy)
@@ -630,7 +630,7 @@
<dependency>
<groupId>commons-configuration</groupId>
<artifactId>commons-configuration</artifactId>
- <version>1.4</version>
+ <version>1.5</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
@@ -642,9 +642,9 @@
<scope>compile</scope>
</dependency>
<dependency>
- <groupId>commons-email</groupId>
+ <groupId>org.apache.commons</groupId>
<artifactId>commons-email</artifactId>
- <version>1.0</version>
+ <version>1.1</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
@@ -651,7 +651,7 @@
<dependency>
<groupId>commons-fileupload</groupId>
<artifactId>commons-fileupload</artifactId>
- <version>1.2</version>
+ <version>1.2.1</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
@@ -658,7 +658,7 @@
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
- <version>1.3.1</version>
+ <version>1.4</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
@@ -672,7 +672,7 @@
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
- <version>1.1</version>
+ <version>1.1.1</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
@@ -679,7 +679,7 @@
<dependency>
<groupId>commons-pool</groupId>
<artifactId>commons-pool</artifactId>
- <version>1.3</version>
+ <version>1.4</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
@@ -777,7 +777,7 @@
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
- <version>1.2.14</version>
+ <version>1.2.15</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
@@ -784,7 +784,7 @@
<dependency>
<groupId>servletapi</groupId>
<artifactId>servletapi</artifactId>
- <version>2.3</version>
+ <version>2.4</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
Index: S:/eclipse-workspace/turbine-2_3/project.xml
===================================================================
--- S:/eclipse-workspace/turbine-2_3/project.xml (revision 647191)
+++ S:/eclipse-workspace/turbine-2_3/project.xml (working copy)
@@ -461,7 +461,7 @@
<dependency>
<groupId>commons-configuration</groupId>
<artifactId>commons-configuration</artifactId>
- <version>1.4</version>
+ <version>1.5</version>
<url>http://commons.apache.org/configuration/</url>
<type>jar</type>
<properties>
@@ -479,9 +479,9 @@
</properties>
</dependency>
<dependency>
- <groupId>commons-email</groupId>
+ <groupId>org.apache.commons</groupId>
<artifactId>commons-email</artifactId>
- <version>1.0</version>
+ <version>1.1</version>
<url>http://commons.apache.org/email/</url>
<type>jar</type>
<properties>
@@ -491,7 +491,7 @@
<dependency>
<groupId>commons-fileupload</groupId>
<artifactId>commons-fileupload</artifactId>
- <version>1.2</version>
+ <version>1.2.1</version>
<url>http://commons.apache.org/fileupload/</url>
<type>jar</type>
<properties>
@@ -501,7 +501,7 @@
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
- <version>1.3.1</version>
+ <version>1.4</version>
<url>http://commons.apache.org/io/</url>
<type>jar</type>
<properties>
@@ -521,7 +521,7 @@
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
- <version>1.1</version>
+ <version>1.1.1</version>
<url>http://commons.apache.org/logging/</url>
<type>jar</type>
<properties>
@@ -531,7 +531,7 @@
<dependency>
<groupId>commons-pool</groupId>
<artifactId>commons-pool</artifactId>
- <version>1.3</version>
+ <version>1.4</version>
<url>http://commons.apache.org/pool/</url>
<type>jar</type>
<properties>
@@ -655,7 +655,7 @@
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
- <version>1.2.14</version>
+ <version>1.2.15</version>
<url>http://logging.apache.org/log4j/</url>
<type>jar</type>
<properties>
@@ -665,7 +665,7 @@
<dependency>
<groupId>servletapi</groupId>
<artifactId>servletapi</artifactId>
- <version>2.3</version>
+ <version>2.4</version>
<url>http://java.sun.com/products/servlet/</url>
<type>jar</type>
<properties>
Index:
S:/eclipse-workspace/turbine-2_3/src/java/org/apache/turbine/util/velocity/VelocityHtmlEmail.java
===================================================================
---
S:/eclipse-workspace/turbine-2_3/src/java/org/apache/turbine/util/velocity/VelocityHtmlEmail.java
(revision 647191)
+++
S:/eclipse-workspace/turbine-2_3/src/java/org/apache/turbine/util/velocity/VelocityHtmlEmail.java
(working copy)
@@ -237,10 +237,10 @@
* @param surl A String.
* @param name A String.
* @return A String with the cid of the embedded file.
- * @exception VelocityEmailException
+ * @exception EmailException
* @see HtmlEmail#embed(URL surl, String name) embed.
*/
- public String embed(String surl, String name) throws
VelocityEmailException
+ public String embed(String surl, String name) throws EmailException
{
String cid = "";
try
Jürgen Hoffmann wrote:
> I have no problem updating those deps as well. Any objections?
>
> Kind regards
>
> Juergen
>
> -----Ursprüngliche Nachricht-----
> Von: Scott Eade [mailto:seade@backstagetech.com.au]
> Gesendet: Freitag, 11. April 2008 14:58
> An: dev@turbine.apache.org
> Betreff: Re: svn commit: r647109 - in /turbine/core/branches/TURBINE_2_3_BRANCH: pom.xml project.properties project.xml
>
> hoffmann@apache.org wrote:
>
>> Author: hoffmann
>> Date: Fri Apr 11 03:53:39 2008
>> New Revision: 647109
>>
>> URL: http://svn.apache.org/viewvc?rev=647109&view=rev
>> Log:
>> updated the dependencies so we can automatically download them from download.java.net/maven
>>
>> Modified:
>> turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml
>> turbine/core/branches/TURBINE_2_3_BRANCH/project.properties
>> turbine/core/branches/TURBINE_2_3_BRANCH/project.xml
>>
>> Modified: turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml
>> URL: http://svn.apache.org/viewvc/turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml?rev=647109&r1=647108&r2=647109&view=diff
>> ==============================================================================
>> --- turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml (original)
>> +++ turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml Fri Apr 11 03:53:39 2008
>> @@ -732,14 +740,14 @@
>> <dependency>
>> <groupId>javax.activation</groupId>
>> <artifactId>activation</artifactId>
>> - <version>1.0.2</version>
>> + <version>1.1.1</version>
>> <type>jar</type>
>> <scope>compile</scope>
>> </dependency>
>> <dependency>
>> <groupId>javax.mail</groupId>
>> <artifactId>mail</artifactId>
>> - <version>1.3.3</version>
>> + <version>1.4.1</version>
>> <type>jar</type>
>> <scope>compile</scope>
>> </dependency>
>>
>> Modified: turbine/core/branches/TURBINE_2_3_BRANCH/project.xml
>> URL: http://svn.apache.org/viewvc/turbine/core/branches/TURBINE_2_3_BRANCH/project.xml?rev=647109&r1=647108&r2=647109&view=diff
>> ==============================================================================
>> --- turbine/core/branches/TURBINE_2_3_BRANCH/project.xml (original)
>> +++ turbine/core/branches/TURBINE_2_3_BRANCH/project.xml Fri Apr 11 03:53:39 2008
>> @@ -601,15 +611,15 @@
>> <dependency>
>> <groupId>javax.activation</groupId>
>> <artifactId>activation</artifactId>
>> - <version>1.0.2</version>
>> - <url>http://java.sun.com/products/javabeans/glasgow/jaf.html</url>
>> + <version>1.1.1</version>
>> + <url>http://download.java.net/maven/1/javax.activation/jars</url>
>> <type>jar</type>
>> </dependency>
>> <dependency>
>> <groupId>javax.mail</groupId>
>> <artifactId>mail</artifactId>
>> - <version>1.3.3</version>
>> - <url>http://java.sun.com/products/javamail/</url>
>> + <version>1.4.1</version>
>> + <url>http://download.java.net/maven/1/javax.mail/jars</url>
>> <type>jar</type>
>> </dependency>
>> <dependency>
>>
>>
> We move to these because we are are now requiring a minimum of J2SE
> 1.4. I know your intention is to do this so that we can avoid the
> manual downloads, but if we are going to update these, why not also do:
> * commons-email-1.1 (requires a very small change to VelocityHtmlEmail,
> see: http://markmail.org/message/tihvveprdobvves7)
> * commons-configuration-1.5
> * commons-fileupload-1.2.1
> * commons-io-1.4
> * commons-logging-1.1.1
> * commons-pool-1.4
> * log4j-1.2.15
> * servletaip-2.4
>
> Seems like a waste not to take this opportunity to push these to the
> latest available releases (that support J2SE 1.4), probably a bit late
> in the process now though.
>
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: AW: svn commit: r647109 - in /turbine/core/branches/TURBINE_2_3_BRANCH:
pom.xml project.properties project.xml
Posted by Scott Eade <se...@backstagetech.com.au>.
Just in case we decide to proceed, here is the patch.
I have successfully built a jar here with this patch applied.
Scott
Index: S:/eclipse-workspace/turbine-2_3/pom.xml
===================================================================
--- S:/eclipse-workspace/turbine-2_3/pom.xml (revision 647191)
+++ S:/eclipse-workspace/turbine-2_3/pom.xml (working copy)
@@ -630,7 +630,7 @@
<dependency>
<groupId>commons-configuration</groupId>
<artifactId>commons-configuration</artifactId>
- <version>1.4</version>
+ <version>1.5</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
@@ -642,9 +642,9 @@
<scope>compile</scope>
</dependency>
<dependency>
- <groupId>commons-email</groupId>
+ <groupId>org.apache.commons</groupId>
<artifactId>commons-email</artifactId>
- <version>1.0</version>
+ <version>1.1</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
@@ -651,7 +651,7 @@
<dependency>
<groupId>commons-fileupload</groupId>
<artifactId>commons-fileupload</artifactId>
- <version>1.2</version>
+ <version>1.2.1</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
@@ -658,7 +658,7 @@
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
- <version>1.3.1</version>
+ <version>1.4</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
@@ -672,7 +672,7 @@
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
- <version>1.1</version>
+ <version>1.1.1</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
@@ -679,7 +679,7 @@
<dependency>
<groupId>commons-pool</groupId>
<artifactId>commons-pool</artifactId>
- <version>1.3</version>
+ <version>1.4</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
@@ -777,7 +777,7 @@
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
- <version>1.2.14</version>
+ <version>1.2.15</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
@@ -784,7 +784,7 @@
<dependency>
<groupId>servletapi</groupId>
<artifactId>servletapi</artifactId>
- <version>2.3</version>
+ <version>2.4</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
Index: S:/eclipse-workspace/turbine-2_3/project.xml
===================================================================
--- S:/eclipse-workspace/turbine-2_3/project.xml (revision 647191)
+++ S:/eclipse-workspace/turbine-2_3/project.xml (working copy)
@@ -461,7 +461,7 @@
<dependency>
<groupId>commons-configuration</groupId>
<artifactId>commons-configuration</artifactId>
- <version>1.4</version>
+ <version>1.5</version>
<url>http://commons.apache.org/configuration/</url>
<type>jar</type>
<properties>
@@ -479,9 +479,9 @@
</properties>
</dependency>
<dependency>
- <groupId>commons-email</groupId>
+ <groupId>org.apache.commons</groupId>
<artifactId>commons-email</artifactId>
- <version>1.0</version>
+ <version>1.1</version>
<url>http://commons.apache.org/email/</url>
<type>jar</type>
<properties>
@@ -491,7 +491,7 @@
<dependency>
<groupId>commons-fileupload</groupId>
<artifactId>commons-fileupload</artifactId>
- <version>1.2</version>
+ <version>1.2.1</version>
<url>http://commons.apache.org/fileupload/</url>
<type>jar</type>
<properties>
@@ -501,7 +501,7 @@
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
- <version>1.3.1</version>
+ <version>1.4</version>
<url>http://commons.apache.org/io/</url>
<type>jar</type>
<properties>
@@ -521,7 +521,7 @@
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
- <version>1.1</version>
+ <version>1.1.1</version>
<url>http://commons.apache.org/logging/</url>
<type>jar</type>
<properties>
@@ -531,7 +531,7 @@
<dependency>
<groupId>commons-pool</groupId>
<artifactId>commons-pool</artifactId>
- <version>1.3</version>
+ <version>1.4</version>
<url>http://commons.apache.org/pool/</url>
<type>jar</type>
<properties>
@@ -655,7 +655,7 @@
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
- <version>1.2.14</version>
+ <version>1.2.15</version>
<url>http://logging.apache.org/log4j/</url>
<type>jar</type>
<properties>
@@ -665,7 +665,7 @@
<dependency>
<groupId>servletapi</groupId>
<artifactId>servletapi</artifactId>
- <version>2.3</version>
+ <version>2.4</version>
<url>http://java.sun.com/products/servlet/</url>
<type>jar</type>
<properties>
Index:
S:/eclipse-workspace/turbine-2_3/src/java/org/apache/turbine/util/velocity/VelocityHtmlEmail.java
===================================================================
---
S:/eclipse-workspace/turbine-2_3/src/java/org/apache/turbine/util/velocity/VelocityHtmlEmail.java
(revision 647191)
+++
S:/eclipse-workspace/turbine-2_3/src/java/org/apache/turbine/util/velocity/VelocityHtmlEmail.java
(working copy)
@@ -237,10 +237,10 @@
* @param surl A String.
* @param name A String.
* @return A String with the cid of the embedded file.
- * @exception VelocityEmailException
+ * @exception EmailException
* @see HtmlEmail#embed(URL surl, String name) embed.
*/
- public String embed(String surl, String name) throws
VelocityEmailException
+ public String embed(String surl, String name) throws EmailException
{
String cid = "";
try
Jürgen Hoffmann wrote:
> I have no problem updating those deps as well. Any objections?
>
> Kind regards
>
> Juergen
>
> -----Ursprüngliche Nachricht-----
> Von: Scott Eade [mailto:seade@backstagetech.com.au]
> Gesendet: Freitag, 11. April 2008 14:58
> An: dev@turbine.apache.org
> Betreff: Re: svn commit: r647109 - in /turbine/core/branches/TURBINE_2_3_BRANCH: pom.xml project.properties project.xml
>
> hoffmann@apache.org wrote:
>
>> Author: hoffmann
>> Date: Fri Apr 11 03:53:39 2008
>> New Revision: 647109
>>
>> URL: http://svn.apache.org/viewvc?rev=647109&view=rev
>> Log:
>> updated the dependencies so we can automatically download them from download.java.net/maven
>>
>> Modified:
>> turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml
>> turbine/core/branches/TURBINE_2_3_BRANCH/project.properties
>> turbine/core/branches/TURBINE_2_3_BRANCH/project.xml
>>
>> Modified: turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml
>> URL: http://svn.apache.org/viewvc/turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml?rev=647109&r1=647108&r2=647109&view=diff
>> ==============================================================================
>> --- turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml (original)
>> +++ turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml Fri Apr 11 03:53:39 2008
>> @@ -732,14 +740,14 @@
>> <dependency>
>> <groupId>javax.activation</groupId>
>> <artifactId>activation</artifactId>
>> - <version>1.0.2</version>
>> + <version>1.1.1</version>
>> <type>jar</type>
>> <scope>compile</scope>
>> </dependency>
>> <dependency>
>> <groupId>javax.mail</groupId>
>> <artifactId>mail</artifactId>
>> - <version>1.3.3</version>
>> + <version>1.4.1</version>
>> <type>jar</type>
>> <scope>compile</scope>
>> </dependency>
>>
>> Modified: turbine/core/branches/TURBINE_2_3_BRANCH/project.xml
>> URL: http://svn.apache.org/viewvc/turbine/core/branches/TURBINE_2_3_BRANCH/project.xml?rev=647109&r1=647108&r2=647109&view=diff
>> ==============================================================================
>> --- turbine/core/branches/TURBINE_2_3_BRANCH/project.xml (original)
>> +++ turbine/core/branches/TURBINE_2_3_BRANCH/project.xml Fri Apr 11 03:53:39 2008
>> @@ -601,15 +611,15 @@
>> <dependency>
>> <groupId>javax.activation</groupId>
>> <artifactId>activation</artifactId>
>> - <version>1.0.2</version>
>> - <url>http://java.sun.com/products/javabeans/glasgow/jaf.html</url>
>> + <version>1.1.1</version>
>> + <url>http://download.java.net/maven/1/javax.activation/jars</url>
>> <type>jar</type>
>> </dependency>
>> <dependency>
>> <groupId>javax.mail</groupId>
>> <artifactId>mail</artifactId>
>> - <version>1.3.3</version>
>> - <url>http://java.sun.com/products/javamail/</url>
>> + <version>1.4.1</version>
>> + <url>http://download.java.net/maven/1/javax.mail/jars</url>
>> <type>jar</type>
>> </dependency>
>> <dependency>
>>
>>
> We move to these because we are are now requiring a minimum of J2SE
> 1.4. I know your intention is to do this so that we can avoid the
> manual downloads, but if we are going to update these, why not also do:
> * commons-email-1.1 (requires a very small change to VelocityHtmlEmail,
> see: http://markmail.org/message/tihvveprdobvves7)
> * commons-configuration-1.5
> * commons-fileupload-1.2.1
> * commons-io-1.4
> * commons-logging-1.1.1
> * commons-pool-1.4
> * log4j-1.2.15
> * servletaip-2.4
>
> Seems like a waste not to take this opportunity to push these to the
> latest available releases (that support J2SE 1.4), probably a bit late
> in the process now though.
>
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
AW: svn commit: r647109 - in /turbine/core/branches/TURBINE_2_3_BRANCH: pom.xml project.properties project.xml
Posted by Jürgen Hoffmann <ho...@ellumination.de>.
I have no problem updating those deps as well. Any objections?
Kind regards
Juergen
-----Ursprüngliche Nachricht-----
Von: Scott Eade [mailto:seade@backstagetech.com.au]
Gesendet: Freitag, 11. April 2008 14:58
An: dev@turbine.apache.org
Betreff: Re: svn commit: r647109 - in /turbine/core/branches/TURBINE_2_3_BRANCH: pom.xml project.properties project.xml
hoffmann@apache.org wrote:
> Author: hoffmann
> Date: Fri Apr 11 03:53:39 2008
> New Revision: 647109
>
> URL: http://svn.apache.org/viewvc?rev=647109&view=rev
> Log:
> updated the dependencies so we can automatically download them from download.java.net/maven
>
> Modified:
> turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml
> turbine/core/branches/TURBINE_2_3_BRANCH/project.properties
> turbine/core/branches/TURBINE_2_3_BRANCH/project.xml
>
> Modified: turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml
> URL: http://svn.apache.org/viewvc/turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml?rev=647109&r1=647108&r2=647109&view=diff
> ==============================================================================
> --- turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml (original)
> +++ turbine/core/branches/TURBINE_2_3_BRANCH/pom.xml Fri Apr 11 03:53:39 2008
> @@ -732,14 +740,14 @@
> <dependency>
> <groupId>javax.activation</groupId>
> <artifactId>activation</artifactId>
> - <version>1.0.2</version>
> + <version>1.1.1</version>
> <type>jar</type>
> <scope>compile</scope>
> </dependency>
> <dependency>
> <groupId>javax.mail</groupId>
> <artifactId>mail</artifactId>
> - <version>1.3.3</version>
> + <version>1.4.1</version>
> <type>jar</type>
> <scope>compile</scope>
> </dependency>
>
> Modified: turbine/core/branches/TURBINE_2_3_BRANCH/project.xml
> URL: http://svn.apache.org/viewvc/turbine/core/branches/TURBINE_2_3_BRANCH/project.xml?rev=647109&r1=647108&r2=647109&view=diff
> ==============================================================================
> --- turbine/core/branches/TURBINE_2_3_BRANCH/project.xml (original)
> +++ turbine/core/branches/TURBINE_2_3_BRANCH/project.xml Fri Apr 11 03:53:39 2008
> @@ -601,15 +611,15 @@
> <dependency>
> <groupId>javax.activation</groupId>
> <artifactId>activation</artifactId>
> - <version>1.0.2</version>
> - <url>http://java.sun.com/products/javabeans/glasgow/jaf.html</url>
> + <version>1.1.1</version>
> + <url>http://download.java.net/maven/1/javax.activation/jars</url>
> <type>jar</type>
> </dependency>
> <dependency>
> <groupId>javax.mail</groupId>
> <artifactId>mail</artifactId>
> - <version>1.3.3</version>
> - <url>http://java.sun.com/products/javamail/</url>
> + <version>1.4.1</version>
> + <url>http://download.java.net/maven/1/javax.mail/jars</url>
> <type>jar</type>
> </dependency>
> <dependency>
>
We move to these because we are are now requiring a minimum of J2SE
1.4. I know your intention is to do this so that we can avoid the
manual downloads, but if we are going to update these, why not also do:
* commons-email-1.1 (requires a very small change to VelocityHtmlEmail,
see: http://markmail.org/message/tihvveprdobvves7)
* commons-configuration-1.5
* commons-fileupload-1.2.1
* commons-io-1.4
* commons-logging-1.1.1
* commons-pool-1.4
* log4j-1.2.15
* servletaip-2.4
Seems like a waste not to take this opportunity to push these to the
latest available releases (that support J2SE 1.4), probably a bit late
in the process now though.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org