date:20070213


[ 
https://issues.apache.org/jira/browse/EMAIL-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472562
 ] 

Ben Speakmon commented on EMAIL-63:
---

Ohhh, I get it. You're right. By all means, put it in there.

 Maven 2 pom.xml
 ---

 Key: EMAIL-63
 URL: https://issues.apache.org/jira/browse/EMAIL-63
 Project: Commons Email
  Issue Type: Improvement
Affects Versions: 1.1
Reporter: Ben Speakmon
 Fix For: 1.1

 Attachments: pom.patch, pom.xml, pomv2.xml, pomv3.xml


 Copied more or less directly from the one just checked in for pool; 
 appropriate substitution made for project info, contributors, dependencies, 
 and test cases.
 One problem: dumbster-SNAPSHOT is not in any Maven 2 repository that I know 
 of and must be manually installed. Everything else seems to work fine.
 Attaching file shortly...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [math] svn commit: r506585 [1/2]

2007-02-13 Thread Jörg Schaible

Luc Maisonobe wrote on Monday, February 12, 2007 11:01 PM:

 Rahul Akolkar wrote :
 On 2/12/07, Luc Maisonobe [EMAIL PROTECTED] wrote:
 
 Yes, it seems many files have strange settings. I use a Linux box
 and on a fresh checkout, I get some files with DOS-like line
 endings. If I set them to a line ending compliant with my local
 host, then set the property to native and then commit the change,
 this will create (hopefully only once) a huge diff. If I understand
 correctly, after that change, further commits will not depend on
 contributor platform. Do you want me to do that or is there a
 smarter way ? 
 
 
 Sounds good, I had earlier missed that you also corrected the
 svn:eol-style!
 
 I will reset the svn:eol-style property for a number of files
 soon. It
 seems 38 text files in the [math] repository do not have any eol-style
 property set. In my local worspace, they show up as 22 with DOS-like
 eol (which is wrong in my box) and 16 with Unix-like eol (which
 is right in
 my box).
 
 I will try to fix everything in two steps for clarity in a
 few minutes.
 You should expect a huge diff when the 22 DOS files will be
 checked in,
 sorry for inconveniance.

BTW: svn will do the conversion automatically if you set the svn:eol-style ...

- Jörg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-commons Wiki] Update of SCXML/Tutorials/Templating by WolfgangFrech

2007-02-13 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki 
for change notification.

The following page has been changed by WolfgangFrech:
http://wiki.apache.org/jakarta-commons/SCXML/Tutorials/Templating

--
  /scxml
  }}}
  
+ 
+ ''Note: not conforming to Working Draft - 
+ As I understand the current Working Draft, a state element with a source 
attribute must not have children. See section 3.2.1.
+ On the other hand, the implementation Commons SCXML v0.6 does accept both the 
src attribute and children for a state element at the same time.
+ See issues.apache.org/jira/browse/SCXML-37
+ - Wolfgang Frech''
+ 
+ 
  === Explanation ===
  The example above is fairly elaborate and simple. As we can see, the 
otherwise complicated State Engine has been broken into three seperate FSMs, 
send-bye.scxml and accept-connection.scxml being fairly reusable.
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: m2 groupIds

2007-02-13 Thread Jörg Schaible

Hi Hen,

Henri Yandell wrote on Tuesday, February 13, 2007 7:00 AM:

 Second try - having had it explained to me on #maven why relocating is
 important [so commons-lang:commons-lang 2.1 and
 org.apache.commons:commons-lang 3.0 are considered the same and a
 transitive clash can be recognized].
 
 So, second suggestion:
 
 We declare a point after which we won't do any more m1 releases. We'll
 move wholesale over to m2. On that day (or as near as we can), we run
 a script on all commons-*/ to do the relocation for all of them (
 http://maven.apache.org/guides/mini/guide-relocation.html ).
 
 I know I'm clueless - so please change this to whatever the clueful
 one is. I think it's time for us to drop m1 and move to m2.

you cannot change the old POMs anymore, in that case this description is 
obsolete. The only valid option is to use the new groupId with a new release 
and provide for this new release a relocation POM at the former location. This 
was Carlos' advice after a two week hassle to do such a transition with XStream.

- Jörg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (EMAIL-62) [email] Build patches to enforce source 1.4 and target 1.4 when compiling

2007-02-13 Thread Piero Ottuzzi (JIRA)


[ 
https://issues.apache.org/jira/browse/EMAIL-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472592
 ] 

Piero Ottuzzi commented on EMAIL-62:


Hi Dion, all,

commons-email 1.0 is quite broken and I think we need to move forward and 
release something working: the actual version has many problems and holding on 
a release for a JDK1.3 compatibility it seems overkill to me.

Just my idea...
Bye
Piero

 [email] Build patches to enforce source 1.4 and target 1.4 when compiling
 -

 Key: EMAIL-62
 URL: https://issues.apache.org/jira/browse/EMAIL-62
 Project: Commons Email
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Ben Speakmon
 Fix For: 1.1

 Attachments: build.xml.patch, project.properties, 
 project.properties.patch


 Maven and Ant patches. Ant patch suppresses spurious 1.5 type safety warnings 
 when building commons-email on JDK = 1.5.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (VFS-110) Changes against VFS-1_0-RC8-SNAPSHOT to use LocalFiles and Webdav files

2007-02-13 Thread Gilles Gaillard (JIRA)

Changes against VFS-1_0-RC8-SNAPSHOT to use LocalFiles and Webdav files
---

 Key: VFS-110
 URL: https://issues.apache.org/jira/browse/VFS-110
 Project: Commons VFS
  Issue Type: Improvement
Affects Versions: later
 Environment: The provided changes were tested against win32 env. and 
webdav servers wabdav_mod /apache, tomcat, sap server
Reporter: Gilles Gaillard
Priority: Minor


Changes provided as attachments were made to use the webdav and local files 
providers.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (VFS-110) Changes against VFS-1_0-RC8-SNAPSHOT to use LocalFiles and Webdav files

2007-02-13 Thread Gilles Gaillard (JIRA)


 [ 
https://issues.apache.org/jira/browse/VFS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles Gaillard updated VFS-110:


Attachment: common-vfs-cvs-13_02_2007.zip
commons-vfs-svn-VFS-1_0-RC8-SNAPSHOT.zip

Here are, as discussed, the original/modified versions of commons vfs:

- commons-vfs-svn-VFS-1_0-RC8-SNAPSHOT.zip contains the original svn checkout 
including first   changes that were made plus the svn directories so that the 
original version is present. Checkout was made on Feb 10, 2006

- common-vfs-cvs-13_02_2007.zip contains the modified as of today



 Changes against VFS-1_0-RC8-SNAPSHOT to use LocalFiles and Webdav files
 ---

 Key: VFS-110
 URL: https://issues.apache.org/jira/browse/VFS-110
 Project: Commons VFS
  Issue Type: Improvement
Affects Versions: later
 Environment: The provided changes were tested against win32 env. and 
 webdav servers wabdav_mod /apache, tomcat, sap server
Reporter: Gilles Gaillard
Priority: Minor
 Attachments: common-vfs-cvs-13_02_2007.zip, 
 commons-vfs-svn-VFS-1_0-RC8-SNAPSHOT.zip


 Changes provided as attachments were made to use the webdav and local files 
 providers.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project commons-jelly-tags-soap (in module commons-jelly) failed

2007-02-13 Thread commons-jelly-tags-soap development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-soap has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 97 runs.
The current state of this project is 'Failed', with reason 'Configuration 
Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-soap :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-soap-13022007.jar] identifier set to 
project name
 -ERROR- No such project [ws-jaxme] for property.
 -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme]
 -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on 
Project:commons-jelly-tags-soap
 -DEBUG- Dependency on ws-axis exists, no need to add for property 
maven.jar.axis.
 -DEBUG- Dependency on ws-axis exists, no need to add for property 
maven.jar.jaxrpc-api.
 -DEBUG- Dependency on ws-axis exists, no need to add for property 
maven.jar.saaj-api.
 -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for 
property maven.jar.servletapi.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -INFO- Failed with reason configuration failed
 -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace
 -INFO- Failed to extract fallback artifacts from Gump Repository

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 2513022007, vmgump.apache.org:vmgump-public:2513022007
Gump E-mail Identifier (unique within run) #42.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project commons-jelly-tags-soap (in module commons-jelly) failed

2007-02-13 Thread commons-jelly-tags-soap development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-soap has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 97 runs.
The current state of this project is 'Failed', with reason 'Configuration 
Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-soap :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-soap-13022007.jar] identifier set to 
project name
 -ERROR- No such project [ws-jaxme] for property.
 -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme]
 -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on 
Project:commons-jelly-tags-soap
 -DEBUG- Dependency on ws-axis exists, no need to add for property 
maven.jar.axis.
 -DEBUG- Dependency on ws-axis exists, no need to add for property 
maven.jar.jaxrpc-api.
 -DEBUG- Dependency on ws-axis exists, no need to add for property 
maven.jar.saaj-api.
 -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for 
property maven.jar.servletapi.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -INFO- Failed with reason configuration failed
 -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace
 -INFO- Failed to extract fallback artifacts from Gump Repository

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-soap/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 2513022007, vmgump.apache.org:vmgump-public:2513022007
Gump E-mail Identifier (unique within run) #42.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (in module commons-jelly) failed

2007-02-13 Thread commons-jelly-tags-jaxme development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-jaxme has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 97 runs.
The current state of this project is 'Failed', with reason 'Configuration 
Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-jaxme :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-jaxme-13022007.jar] identifier set to 
project name
 -ERROR- No such project [ws-jaxme] for property.
 -ERROR- No such project [ws-jaxme] for property.
 -ERROR- No such project [ws-jaxme] for property.
 -ERROR- No such project [ws-jaxme] for property.
 -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme]
 -ERROR- Unhandled Property: maven.jar.jaxme-js on: Maven on 
Project:commons-jelly-tags-jaxme
 -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme]
 -ERROR- Unhandled Property: maven.jar.jaxme on: Maven on 
Project:commons-jelly-tags-jaxme
 -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme]
 -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on 
Project:commons-jelly-tags-jaxme
 -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme]
 -ERROR- Unhandled Property: maven.jar.jaxme-xs on: Maven on 
Project:commons-jelly-tags-jaxme
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -INFO- Failed with reason configuration failed
 -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace
 -INFO- Failed to extract fallback artifacts from Gump Repository

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 2513022007, vmgump.apache.org:vmgump-public:2513022007
Gump E-mail Identifier (unique within run) #45.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project commons-jelly-tags-jaxme (in module commons-jelly) failed

2007-02-13 Thread commons-jelly-tags-jaxme development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-jaxme has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 97 runs.
The current state of this project is 'Failed', with reason 'Configuration 
Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-jaxme :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-jaxme-13022007.jar] identifier set to 
project name
 -ERROR- No such project [ws-jaxme] for property.
 -ERROR- No such project [ws-jaxme] for property.
 -ERROR- No such project [ws-jaxme] for property.
 -ERROR- No such project [ws-jaxme] for property.
 -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme]
 -ERROR- Unhandled Property: maven.jar.jaxme-js on: Maven on 
Project:commons-jelly-tags-jaxme
 -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme]
 -ERROR- Unhandled Property: maven.jar.jaxme on: Maven on 
Project:commons-jelly-tags-jaxme
 -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme]
 -ERROR- Unhandled Property: maven.jar.jaxme-api on: Maven on 
Project:commons-jelly-tags-jaxme
 -ERROR- Cannot resolve output/outputpath of *unknown* [ws-jaxme]
 -ERROR- Unhandled Property: maven.jar.jaxme-xs on: Maven on 
Project:commons-jelly-tags-jaxme
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -INFO- Failed with reason configuration failed
 -ERROR- Bad Dependency. Project: ws-jaxme unknown to *this* workspace
 -INFO- Failed to extract fallback artifacts from Gump Repository

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jaxme/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 2513022007, vmgump.apache.org:vmgump-public:2513022007
Gump E-mail Identifier (unique within run) #45.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: m2 groupIds


On 2/13/07, Jörg Schaible [EMAIL PROTECTED] wrote:

Hi Hen,

Henri Yandell wrote on Tuesday, February 13, 2007 7:00 AM:

 Second try - having had it explained to me on #maven why relocating is
 important [so commons-lang:commons-lang 2.1 and
 org.apache.commons:commons-lang 3.0 are considered the same and a
 transitive clash can be recognized].

 So, second suggestion:

 We declare a point after which we won't do any more m1 releases. We'll
 move wholesale over to m2. On that day (or as near as we can), we run
 a script on all commons-*/ to do the relocation for all of them (
 http://maven.apache.org/guides/mini/guide-relocation.html ).

 I know I'm clueless - so please change this to whatever the clueful
 one is. I think it's time for us to drop m1 and move to m2.

you cannot change the old POMs anymore, in that case this description is 
obsolete. The only
valid option is to use the new groupId with a new release and provide for this 
new release a
relocation POM at the former location. This was Carlos' advice after a two week 
hassle to do
such a transition with XStream.


So we're cursed with having to do relocation poms every time we do a release?

Is that something we can put in the parent pom?

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: m2 groupIds


You need to create a relocation POM for the release that does relocation to
avoid hundred users to ask for upload on ibilio.
The relocation POM will produce a warning on console for maven users. You
can expect users to consider warnings and update groupId.

The relocation POM will not be required for N+1 releases. You MAY publish
one if you consider not all users had time to update. This is similar to
@deprecation warning in code : you can keep old code for some time but users
are warned that it will be removed.

2007/2/13, Henri Yandell [EMAIL PROTECTED]:


On 2/13/07, Jörg Schaible [EMAIL PROTECTED] wrote:
 Hi Hen,

 Henri Yandell wrote on Tuesday, February 13, 2007 7:00 AM:

  Second try - having had it explained to me on #maven why relocating is
  important [so commons-lang:commons-lang 2.1 and
  org.apache.commons:commons-lang 3.0 are considered the same and a
  transitive clash can be recognized].
 
  So, second suggestion:
 
  We declare a point after which we won't do any more m1 releases. We'll
  move wholesale over to m2. On that day (or as near as we can), we run
  a script on all commons-*/ to do the relocation for all of them (
  http://maven.apache.org/guides/mini/guide-relocation.html ).
 
  I know I'm clueless - so please change this to whatever the clueful
  one is. I think it's time for us to drop m1 and move to m2.

 you cannot change the old POMs anymore, in that case this description is
obsolete. The only
 valid option is to use the new groupId with a new release and provide
for this new release a
 relocation POM at the former location. This was Carlos' advice after a
two week hassle to do
 such a transition with XStream.

So we're cursed with having to do relocation poms every time we do a
release?

Is that something we can put in the parent pom?

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (NET-151) [PATCH] Allow user to force passive connections to use connected host in FTPClient

2007-02-13 Thread Neil Aggarwal (JIRA)

[
https://issues.apache.org/jira/browse/NET-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Neil Aggarwal updated NET-151:
--

Attachment: FTPClientOverrideHost.patch.txt

Steffen Heil [EMAIL PROTECTED] suggested to use a method with this signature:
overrideHostForPassiveConnections(InetAddress)
which is a more elegant solution.

This patch implements that method. Use this instead of the previous patch.

[PATCH] Allow user to force passive connections to use connected host in
FTPClient
--

Key: NET-151
URL: https://issues.apache.org/jira/browse/NET-151
Project: Commons Net
Issue Type: Improvement
Affects Versions: 2.0
Environment: Windows XP, Java 1.5.0, Intel processor
Reporter: Neil Aggarwal
Attachments: FTPClient.patch.txt, FTPClientOverrideHost.patch.txt

Currently, FTPClient always uses the host and port returned to it from the
reply to a passive connection request.
Some FTP hosts are set incorrectly or are set behind a NAT so they report the
incorrect IP address to use for the connection and the transfer will fail to
connect.
This patch allows the user to tell FTPClient to use the connected host
instead of the host given from the passive reply.
Doing so will allow successful transfers even when the report FTP server
returns an incorrect IP address.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[RESULT] IO 1.3.1 (RC3)


Vote passed with +1s from:

(PMC)
Niall Pemberton
Gary Gregory
Stephen Colebourne
Rahul Akolkar
Simon Kitching (voted on RC1)

(non-PMC)
Jörg Schaible

Release will go out today.

Hen

On 2/9/07, Henri Yandell [EMAIL PROTECTED] wrote:

Going with RC3:

http://people.apache.org/~bayard/commons-io/1.3.1-rc3/

The only change is that I've fixed the manifest to say 1.3.1 and not 1.3.

 [ ] +1
 [ ] -1

Hen



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [RESULT] IO 1.3.1 (RC3)


[Apologies for spam...]

Jörg Schaible is on the PMC too. I missed his name in the list when scanning.

Hen


On 2/13/07, Henri Yandell [EMAIL PROTECTED] wrote:

Vote passed with +1s from:

(PMC)
Niall Pemberton
Gary Gregory
Stephen Colebourne
Rahul Akolkar
Simon Kitching (voted on RC1)

(non-PMC)
Jörg Schaible

Release will go out today.

Hen

On 2/9/07, Henri Yandell [EMAIL PROTECTED] wrote:
 Going with RC3:

 http://people.apache.org/~bayard/commons-io/1.3.1-rc3/

 The only change is that I've fixed the manifest to say 1.3.1 and not 1.3.

  [ ] +1
  [ ] -1

 Hen




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[RESULT] Lang 2.3 (RC3)


Vote passed for Lang 2.3.

+1s from:

(PMC)

Jörg Schaible
Niall Pemberton
Oliver Heger
Gary Gregory
Rahul Akolkar
Stephen Colebourne (voted on RC1)

The release will go out today.

Hen

On 2/9/07, Henri Yandell [EMAIL PROTECTED] wrote:

Here's the 3rd release candidate for Lang 2.3:

http://people.apache.org/~bayard/commons-lang/commons-lang-2.3-rc3/

Clirr, Jardiff + Site included.

[ ] +1
[ ] -1

Difference from RC2 is that the sources and javadoc jars now have
LICENSE/NOTICE files and the test for LANG-312 is commented out as
it's still an open bug (and fails on some platforms).

The pom.xml is NOT in the src bundle, because I forgot and I don't
want to do all that again :) I'll make that change in svn now so it'll
be in a future RC if one happens.

Hen



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507079 - in /jakarta/commons/proper/io/trunk: build.xml pom.xml project.xml

Author: bayard
Date: Tue Feb 13 08:30:47 2007
New Revision: 507079

URL: http://svn.apache.org/viewvc?view=revrev=507079
Log:
Moving to 1.4-SNAPSHOT

Modified:
jakarta/commons/proper/io/trunk/build.xml
jakarta/commons/proper/io/trunk/pom.xml
jakarta/commons/proper/io/trunk/project.xml

Modified: jakarta/commons/proper/io/trunk/build.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/build.xml?view=diffrev=507079r1=507078r2=507079
==
--- jakarta/commons/proper/io/trunk/build.xml (original)
+++ jakarta/commons/proper/io/trunk/build.xml Tue Feb 13 08:30:47 2007
@@ -26,7 +26,7 @@
   /property
   property name=testreportdir value=${basedir}/build/test-reports
   /property
-  property name=final.name value=commons-io-1.3.1 /
+  property name=final.name value=commons-io-1.4-SNAPSHOT /
   property name=dist.build.dir value=${basedir}/build/dist-build /
   property name=dist.bin value=${dist.build.dir}/${final.name} /
   property name=dist.src value=${dist.build.dir}/${final.name}-src /
@@ -272,7 +272,7 @@
 /tstamp
 property name=copyright value=Copyright amp;copy;  The Apache 
Software Foundation. All Rights Reserved.
 /property
-property name=title value=IO 1.3.1
+property name=title value=IO 1.4-SNAPSHOT
 /property
 javadoc use=true private=true destdir=${javadocdir} author=true 
version=true sourcepath=${basedir}/src/java 
packagenames=org.apache.commons.io.* 
overview=src/java/org/apache/commons/io/overview.html
   classpath

Modified: jakarta/commons/proper/io/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/pom.xml?view=diffrev=507079r1=507078r2=507079
==
--- jakarta/commons/proper/io/trunk/pom.xml (original)
+++ jakarta/commons/proper/io/trunk/pom.xml Tue Feb 13 08:30:47 2007
@@ -27,7 +27,7 @@
   modelVersion4.0.0/modelVersion
   groupIdcommons-io/groupId
   artifactIdcommons-io/artifactId
-  version1.3.1/version
+  version1.4-SNAPSHOT/version
   nameIO/name
 
   inceptionYear2002/inceptionYear

Modified: jakarta/commons/proper/io/trunk/project.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/io/trunk/project.xml?view=diffrev=507079r1=507078r2=507079
==
--- jakarta/commons/proper/io/trunk/project.xml (original)
+++ jakarta/commons/proper/io/trunk/project.xml Tue Feb 13 08:30:47 2007
@@ -21,7 +21,7 @@
   nameIO/name
   groupIdcommons-io/groupId
   artifactIdcommons-io/artifactId
-  currentVersion1.3.1/currentVersion
+  currentVersion1.4-SNAPSHOT/currentVersion
   inceptionYear2002/inceptionYear
   shortDescriptionCommons IO/shortDescription
   description



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507081 - in /jakarta/commons/proper/lang/trunk: default.properties pom.xml project.xml

Author: bayard
Date: Tue Feb 13 08:31:25 2007
New Revision: 507081

URL: http://svn.apache.org/viewvc?view=revrev=507081
Log:
Moving to the next version - which I'm claiming will be 3.0

Modified:
jakarta/commons/proper/lang/trunk/default.properties
jakarta/commons/proper/lang/trunk/pom.xml
jakarta/commons/proper/lang/trunk/project.xml

Modified: jakarta/commons/proper/lang/trunk/default.properties
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/default.properties?view=diffrev=507081r1=507080r2=507081
==
--- jakarta/commons/proper/lang/trunk/default.properties (original)
+++ jakarta/commons/proper/lang/trunk/default.properties Tue Feb 13 08:31:25 
2007
@@ -33,7 +33,7 @@
 component.title = Core Language Utilities
 
 # The current version number of this component
-component.version = 2.3
+component.version = 3.0-SNAPSHOT
 
 # The current year used for the end date in copyrights.
 copyright.end = 2005

Modified: jakarta/commons/proper/lang/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/pom.xml?view=diffrev=507081r1=507080r2=507081
==
--- jakarta/commons/proper/lang/trunk/pom.xml (original)
+++ jakarta/commons/proper/lang/trunk/pom.xml Tue Feb 13 08:31:25 2007
@@ -27,7 +27,7 @@
   modelVersion4.0.0/modelVersion
   groupIdcommons-lang/groupId
   artifactIdcommons-lang/artifactId
-  version2.3/version
+  version3.0-SNAPSHOT/version
   nameLang/name
 
   inceptionYear2001/inceptionYear

Modified: jakarta/commons/proper/lang/trunk/project.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/lang/trunk/project.xml?view=diffrev=507081r1=507080r2=507081
==
--- jakarta/commons/proper/lang/trunk/project.xml (original)
+++ jakarta/commons/proper/lang/trunk/project.xml Tue Feb 13 08:31:25 2007
@@ -20,7 +20,7 @@
 groupIdcommons-lang/groupId
 artifactIdcommons-lang/artifactId
 nameLang/name
-currentVersion2.3/currentVersion
+currentVersion3.0-SNAPSHOT/currentVersion
 inceptionYear2001/inceptionYear
 shortDescriptionJava Common Components/shortDescription
 description



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507089 - /jakarta/commons/proper/lang/tags/LANG_2_3/

Author: bayard
Date: Tue Feb 13 08:53:07 2007
New Revision: 507089

URL: http://svn.apache.org/viewvc?view=revrev=507089
Log:
Releasing Lang 2.3 from the rc3

Added:
jakarta/commons/proper/lang/tags/LANG_2_3/
  - copied from r507088, jakarta/commons/proper/lang/tags/LANG_2_3_RC3/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507090 - /jakarta/commons/proper/io/tags/IO_1_3_1/

Author: bayard
Date: Tue Feb 13 08:53:32 2007
New Revision: 507090

URL: http://svn.apache.org/viewvc?view=revrev=507090
Log:
Releasing IO 1.3.1 from the rc3

Added:
jakarta/commons/proper/io/tags/IO_1_3_1/
  - copied from r507089, jakarta/commons/proper/io/tags/IO_1_3_1_RC3/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed

2007-02-13 Thread commons-jelly-tags-jsl development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-jsl-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 26 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-jsl-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on ant exists, no need to add for property 
maven.jar.ant-optional.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html
Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 25 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-13022007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-13022007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-13022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-13022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-13022007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-13022007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187)
[junit] at 
org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66)
[junit] at 
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187)
[junit] at 
org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59)
[junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80)
[junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171)
[junit]

[EMAIL PROTECTED]: Project commons-jelly-tags-jsl-test (in module commons-jelly) failed

2007-02-13 Thread commons-jelly-tags-jsl development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-jsl-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 26 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-jsl-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on ant exists, no need to add for property 
maven.jar.ant-optional.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jsl-test/gump_work/build_commons-jelly_commons-jelly-tags-jsl-test.html
Work Name: build_commons-jelly_commons-jelly-tags-jsl-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 25 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/jsl]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/commons-cli-1.0.x/target/commons-cli-13022007.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/log/target/commons-jelly-tags-log-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/commons-jelly-tags-xml-13022007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-13022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-13022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-13022007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-13022007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar
-
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTagSupport.fail(AssertTagSupport.java:64)
[junit] at 
org.apache.commons.jelly.tags.junit.AssertTag.doTag(AssertTag.java:59)
[junit] at 
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:263)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187)
[junit] at 
org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:66)
[junit] at 
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:113)
[junit] at 
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96)
[junit] at 
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:187)
[junit] at 
org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java:161)
[junit] at org.dom4j.rule.Mode.fireRule(Mode.java:59)
[junit] at org.dom4j.rule.Mode.applyTemplates(Mode.java:80)
[junit] at org.dom4j.rule.RuleManager$1.run(RuleManager.java:171)
[junit]

Re: [VOTE] Release Commons DBCP 1.2.2


* keys good, md5s good.
* source compiles happily with maven1 and has the same number of files
in as the published jar.
* site looks good.

+1

Remember to deploy the jar and pom to the m1 repository when releasing
(as they're not in the rc).

Hen

On 2/11/07, Phil Steitz [EMAIL PROTECTED] wrote:

There have been no significant issues reported against DBCP 1.2.2-RC1, which
has been available for a couple of weeks now, so I would like to call for a
release vote, based on the distribution below.

Since RC1, the following changes have been made;

* Fixed copyright end date in NOTICE.txt
* Compiled with jdk 1.4.2_10
* Added file names to md5's
* Added signing key to KEYS file
* Fixed errors in downloads web page and eliminated extra API docs link

Thanks to all who provided feedback on RC1.

The release zips/tarballs are here:

http://people.apache.org/~psteitz/dbcp-1.2.2-RC2/http://people.apache.org/%7Epsteitz/dbcp-1.2.2-RC1/

Please note that, despite the release names, these distributions are *not*
official apache releases, so should be used only for inspection/verification
during the duration of this VOTE.

Release notes:
http://people.apache.org/~psteitz/dbcp-1.2.2-RC2/RELEASE-NOTES.txt
http://people.apache.org/%7Epsteitz/dbcp-1.2.2-RC1/RELEASE-NOTES.txt

Web site:
http://people.apache.org/~psteitz/dbcp-1.2.2-RC2/docs/http://people.apache.org/%7Epsteitz/dbcp-1.2.2-RC1/docs/

The svn tag is DBCP_1_2_2-RC2.  Assuming a successful VOTE, I will copy the
tag to DBCP_1_2_2 and move the distributions above to the mirrors.

Votes, please.  The vote will close end of day (GMT) 15-Feb-2007.

-
[  ] +1 - Yes, release these bits
[  ] +0  - OK...
[  ] -0  -  OK, but...
[  ] -1  - No, because


Thanks,

Phil



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed

2007-02-13 Thread commons-jelly-tags-fmt development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-fmt-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 26 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-fmt-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html
Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 18 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-13022007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-13022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-13022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-13022007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-13022007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-13022007.jar
-
[junit] at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
[junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
[junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
[junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
[junit] at java.security.AccessController.doPrivileged(Native Method)
[junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
[junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
[junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
[junit] at 
org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)

[EMAIL PROTECTED]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed

2007-02-13 Thread commons-jelly-tags-fmt development

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project commons-jelly-tags-fmt-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 26 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-fmt-test :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -WARNING- Overriding Maven properties: 
[/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties]
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html
Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 18 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-13022007.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-13022007.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-13022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-13022007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-13022007.jar:/usr/local/gump/public/workspace/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-13022007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags-fmt-13022007.jar
-
[junit] at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
[junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
[junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
[junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
[junit] at java.security.AccessController.doPrivileged(Native Method)
[junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
[junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
[junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
[junit] at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
[junit] at 
org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128)

svn commit: r507122 - /jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java

2007-02-13 Thread olegk

Author: olegk
Date: Tue Feb 13 10:01:48 2007
New Revision: 507122

URL: http://svn.apache.org/viewvc?view=revrev=507122
Log:
HTTPCLIENT-630: Made readObject/writeObject methods private

Modified:

jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java

Modified: 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java?view=diffrev=507122r1=507121r2=507122
==
--- 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java
 (original)
+++ 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/URI.java
 Tue Feb 13 10:01:48 2007
@@ -3606,7 +3606,7 @@
  * @param oos the object-output stream
  * @throws IOException If an IO problem occurs.
  */
-protected void writeObject(ObjectOutputStream oos)
+private void writeObject(ObjectOutputStream oos)
 throws IOException {
 
 oos.defaultWriteObject();
@@ -3621,7 +3621,7 @@
  * input stream cannot be found.
  * @throws IOException If an IO problem occurs.
  */
-protected void readObject(ObjectInputStream ois)
+private void readObject(ObjectInputStream ois)
 throws ClassNotFoundException, IOException {
 
 ois.defaultReadObject();



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: m2 groupIds

2007-02-13 Thread Dennis Lundberg


Thanks for bringing this up Henri.

Here's my view on this:

1. Maven 1 builds stay as commons-foo (like you said)

2. Maven 2 builds change to org.apache.commons once the component moves 
to using M2 to build the component *and* putting the artifacts into the 
M2 repo. This should be done one component at a time - not all at once.


As for how to handle relocations I'll talk to the Maven community to get 
some more feedback.


Henri Yandell wrote:

Second try - having had it explained to me on #maven why relocating is
important [so commons-lang:commons-lang 2.1 and
org.apache.commons:commons-lang 3.0 are considered the same and a
transitive clash can be recognized].

So, second suggestion:

We declare a point after which we won't do any more m1 releases. We'll
move wholesale over to m2. On that day (or as near as we can), we run
a script on all commons-*/ to do the relocation for all of them (
http://maven.apache.org/guides/mini/guide-relocation.html ).

I know I'm clueless - so please change this to whatever the clueful
one is. I think it's time for us to drop m1 and move to m2.

Hen

On 2/12/07, Henri Yandell [EMAIL PROTECTED] wrote:

This has come up a number of times and I'm not sure if the last time
saw an agreement.

My understanding is that we want to move to org.apache.commons. We've
dabbled with the idea of relocating, but it sounds like that is more
trouble than it's worth. Are we now of the view that:

1) Maven-1 builds stay as commons-foo
2) Maven-2 builds all set the groupId to org.apache.commons

??

Hen



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507134 - in /jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/cookie: RFC2109Spec.java RFC2965Spec.java

2007-02-13 Thread olegk

Author: olegk
Date: Tue Feb 13 10:18:05 2007
New Revision: 507134

URL: http://svn.apache.org/viewvc?view=revrev=507134
Log:
HTTPCLIENT-631: RFC2109Spec#SET_COOKIE_KEY, RFC2965Spec#SET_COOKIE2_KEY static 
variables made final

Modified:

jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/cookie/RFC2109Spec.java

jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/cookie/RFC2965Spec.java

Modified: 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/cookie/RFC2109Spec.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/cookie/RFC2109Spec.java?view=diffrev=507134r1=507133r2=507134
==
--- 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/cookie/RFC2109Spec.java
 (original)
+++ 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/cookie/RFC2109Spec.java
 Tue Feb 13 10:18:05 2007
@@ -59,7 +59,7 @@
  * Cookie Response Header  name for cookies processed
  * by this spec.
  */
-public static String SET_COOKIE_KEY = set-cookie;
+public final static String SET_COOKIE_KEY = set-cookie;
 
 /** Default constructor */
 public RFC2109Spec() {

Modified: 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/cookie/RFC2965Spec.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/cookie/RFC2965Spec.java?view=diffrev=507134r1=507133r2=507134
==
--- 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/cookie/RFC2965Spec.java
 (original)
+++ 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/cookie/RFC2965Spec.java
 Tue Feb 13 10:18:05 2007
@@ -62,7 +62,7 @@
 * Cookie Response Header  name for cookies processed
 * by this spec.
 */
-public static String SET_COOKIE2_KEY = set-cookie2;
+public final static String SET_COOKIE2_KEY = set-cookie2;
 
 /**
 * used for formatting RFC 2956 style cookies



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: m2 groupIds


you can change the old poms to relocate to a new location as long as
the new location has the same old jars and poms (just groupId change).
IIRC your case was different.

So, I' see two options for relocation:

1) when new version is out with new groupId add relocation pom in old
location just for that new version.
+ Users updating version in old location will get a warning
+ easy to do
 - users may end having old versions and new versions in the
classpath, that they would have to solve with exclusions

2) relocate all versions to new groupId
+ all users will only notice the warnings when using old group
+ no classpath problems in builds from scratch
- harder to implement, will need to write some code
- people with commons artifacts cached (almost everybody) will
experience same problems as in 1, possibly getting two versions in the
classpath

I'd stick with 1) changing old releases scares me ;) and still doesn't
guarantee trouble free upgrades



On 2/13/07, Jörg Schaible [EMAIL PROTECTED] wrote:

you cannot change the old POMs anymore, in that case this description is 
obsolete. The only valid option is to use the new groupId with a new release 
and provide for this new release a relocation POM at the former location. This 
was Carlos' advice after a two week hassle to do such a transition with XStream.

- Jörg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507149 - /jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpHost.java

2007-02-13 Thread olegk

Author: olegk
Date: Tue Feb 13 10:34:15 2007
New Revision: 507149

URL: http://svn.apache.org/viewvc?view=revrev=507149
Log:
HTTPCLIENT-632: Removed superfluous null check

Modified:

jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpHost.java

Modified: 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpHost.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpHost.java?view=diffrev=507149r1=507148r2=507149
==
--- 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpHost.java
 (original)
+++ 
jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/HttpHost.java
 Tue Feb 13 10:34:15 2007
@@ -159,10 +159,8 @@
  */
 public String toURI() {
 StringBuffer buffer = new StringBuffer(50);
-if (this.protocol != null) {
-buffer.append(this.protocol.getScheme());
-buffer.append(://);
-}
+buffer.append(this.protocol.getScheme());
+buffer.append(://);
 buffer.append(this.hostname);
 if (this.port != this.protocol.getDefaultPort()) {
 buffer.append(':');



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: m2 groupIds


oh there's a 3rd option that I even like more

3) make new releases in new groupid, no relocations at all
+ easiest ;)
+ users trying to upgrade will need to know that the groupId has
changed and act by themselves, so they will be involved, and in case
of classpath problems they will know what has changed
- it'd be better to wait until a major/minor release so users can get
bugfixes easily


On 2/13/07, Carlos Sanchez [EMAIL PROTECTED] wrote:

you can change the old poms to relocate to a new location as long as
the new location has the same old jars and poms (just groupId change).
IIRC your case was different.

So, I' see two options for relocation:

1) when new version is out with new groupId add relocation pom in old
location just for that new version.
 + Users updating version in old location will get a warning
 + easy to do
  - users may end having old versions and new versions in the
classpath, that they would have to solve with exclusions

2) relocate all versions to new groupId
 + all users will only notice the warnings when using old group
 + no classpath problems in builds from scratch
 - harder to implement, will need to write some code
 - people with commons artifacts cached (almost everybody) will
experience same problems as in 1, possibly getting two versions in the
classpath

I'd stick with 1) changing old releases scares me ;) and still doesn't
guarantee trouble free upgrades



On 2/13/07, Jörg Schaible [EMAIL PROTECTED] wrote:
 you cannot change the old POMs anymore, in that case this description is 
obsolete. The only valid option is to use the new groupId with a new release and 
provide for this new release a relocation POM at the former location. This was 
Carlos' advice after a two week hassle to do such a transition with XStream.

 - Jörg

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (EMAIL-62) [email] Build patches to enforce source 1.4 and target 1.4 when compiling


[ 
https://issues.apache.org/jira/browse/EMAIL-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472839
 ] 

Ben Speakmon commented on EMAIL-62:
---

I'm with Dion 100% on meeting the needs of users, but as I said on the list, I 
consider the benefits of using 1.4 -- allowing us to use the latest 
javamail/activation versions, much better charset support, etc. -- outweigh the 
new dependencies. It's better than asking users to stick with the known bugs of 
javamail 1.3.1 and being forced to reimplement the charset code in 1.3 when the 
majority of people using it are on at least 1.4.

It's not my project, though, and if 1.4 is unacceptable for some other reason, 
we'll think of something clever. As Piero says, the important thing is to get 
fixes out for what's not working.

 [email] Build patches to enforce source 1.4 and target 1.4 when compiling
 -

 Key: EMAIL-62
 URL: https://issues.apache.org/jira/browse/EMAIL-62
 Project: Commons Email
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Ben Speakmon
 Fix For: 1.1

 Attachments: build.xml.patch, project.properties, 
 project.properties.patch


 Maven and Ant patches. Ant patch suppresses spurious 1.5 type safety warnings 
 when building commons-email on JDK = 1.5.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507169 - /jakarta/commons/proper/commons-parent/trunk/pom.xml

2007-02-13 Thread dennisl

Author: dennisl
Date: Tue Feb 13 11:24:09 2007
New Revision: 507169

URL: http://svn.apache.org/viewvc?view=revrev=507169
Log:
Add maven-gpg-plugin to the release and rc profiles.

Modified:
jakarta/commons/proper/commons-parent/trunk/pom.xml

Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/commons-parent/trunk/pom.xml?view=diffrev=507169r1=507168r2=507169
==
--- jakarta/commons/proper/commons-parent/trunk/pom.xml (original)
+++ jakarta/commons/proper/commons-parent/trunk/pom.xml Tue Feb 13 11:24:09 2007
@@ -100,6 +100,11 @@
   plugins
 plugin
   groupIdorg.apache.maven.plugins/groupId
+  artifactIdmaven-gpg-plugin/artifactId
+  version1.0-alpha-1/version
+/plugin
+plugin
+  groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-jar-plugin/artifactId
   version2.1/version
 /plugin
@@ -199,6 +204,22 @@
   /distributionManagement
   build
 plugins
+  !-- We want to sign the artifact, the POM, and all attached 
artifacts --
+  plugin
+artifactIdmaven-gpg-plugin/artifactId
+configuration
+  passphrase${gpg.passphrase}/passphrase
+/configuration
+executions
+  execution
+idsign-artifacts/id
+phaseverify/phase
+goals
+  goalsign/goal
+/goals
+  /execution
+/executions
+  /plugin
   plugin
 artifactIdmaven-source-plugin/artifactId
 executions
@@ -243,6 +264,22 @@
   /distributionManagement
   build
 plugins
+  !-- We want to sign the artifact, the POM, and all attached 
artifacts --
+  plugin
+artifactIdmaven-gpg-plugin/artifactId
+configuration
+  passphrase${gpg.passphrase}/passphrase
+/configuration
+executions
+  execution
+idsign-artifacts/id
+phaseverify/phase
+goals
+  goalsign/goal
+/goals
+  /execution
+/executions
+  /plugin
   plugin
 artifactIdmaven-source-plugin/artifactId
 executions



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: m2 groupIds


I don't understand the distinction you make between scenario 1 and 3 :

if new release use a relocation pom under commons-xxx and DOESN'T deploy a
jar under this group
- maven2 users will get relocated artifact + a warning to update
dependencies
- maven1 users will not get the new version, may ask for it or only found
the POM and will update dependencies

am I wrong ?

Nico.



2007/2/13, Carlos Sanchez [EMAIL PROTECTED]:


oh there's a 3rd option that I even like more

3) make new releases in new groupid, no relocations at all
+ easiest ;)
+ users trying to upgrade will need to know that the groupId has
changed and act by themselves, so they will be involved, and in case
of classpath problems they will know what has changed
- it'd be better to wait until a major/minor release so users can get
bugfixes easily


On 2/13/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
 you can change the old poms to relocate to a new location as long as
 the new location has the same old jars and poms (just groupId change).
 IIRC your case was different.

 So, I' see two options for relocation:

 1) when new version is out with new groupId add relocation pom in old
 location just for that new version.
  + Users updating version in old location will get a warning
  + easy to do
   - users may end having old versions and new versions in the
 classpath, that they would have to solve with exclusions

 2) relocate all versions to new groupId
  + all users will only notice the warnings when using old group
  + no classpath problems in builds from scratch
  - harder to implement, will need to write some code
  - people with commons artifacts cached (almost everybody) will
 experience same problems as in 1, possibly getting two versions in the
 classpath

 I'd stick with 1) changing old releases scares me ;) and still doesn't
 guarantee trouble free upgrades



 On 2/13/07, Jörg Schaible [EMAIL PROTECTED] wrote:
  you cannot change the old POMs anymore, in that case this description
is obsolete. The only valid option is to use the new groupId with a new
release and provide for this new release a relocation POM at the former
location. This was Carlos' advice after a two week hassle to do such a
transition with XStream.
 
  - Jörg
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


 --
 I could give you my word as a Spaniard.
 No good. I've known too many Spaniards.
  -- The Princess Bride



--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: m2 groupIds


scenario 3 is with no relocation pom at all, so users get involved by
having to explicitly change the groupId

On 2/13/07, nicolas de loof [EMAIL PROTECTED] wrote:

I don't understand the distinction you make between scenario 1 and 3 :

if new release use a relocation pom under commons-xxx and DOESN'T deploy a
jar under this group
- maven2 users will get relocated artifact + a warning to update
dependencies
- maven1 users will not get the new version, may ask for it or only found
the POM and will update dependencies

am I wrong ?

Nico.



2007/2/13, Carlos Sanchez [EMAIL PROTECTED]:

 oh there's a 3rd option that I even like more

 3) make new releases in new groupid, no relocations at all
 + easiest ;)
 + users trying to upgrade will need to know that the groupId has
 changed and act by themselves, so they will be involved, and in case
 of classpath problems they will know what has changed
 - it'd be better to wait until a major/minor release so users can get
 bugfixes easily


 On 2/13/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
  you can change the old poms to relocate to a new location as long as
  the new location has the same old jars and poms (just groupId change).
  IIRC your case was different.
 
  So, I' see two options for relocation:
 
  1) when new version is out with new groupId add relocation pom in old
  location just for that new version.
   + Users updating version in old location will get a warning
   + easy to do
- users may end having old versions and new versions in the
  classpath, that they would have to solve with exclusions
 
  2) relocate all versions to new groupId
   + all users will only notice the warnings when using old group
   + no classpath problems in builds from scratch
   - harder to implement, will need to write some code
   - people with commons artifacts cached (almost everybody) will
  experience same problems as in 1, possibly getting two versions in the
  classpath
 
  I'd stick with 1) changing old releases scares me ;) and still doesn't
  guarantee trouble free upgrades
 
 
 
  On 2/13/07, Jörg Schaible [EMAIL PROTECTED] wrote:
   you cannot change the old POMs anymore, in that case this description
 is obsolete. The only valid option is to use the new groupId with a new
 release and provide for this new release a relocation POM at the former
 location. This was Carlos' advice after a two week hassle to do such a
 transition with XStream.
  
   - Jörg
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
 
  --
  I could give you my word as a Spaniard.
  No good. I've known too many Spaniards.
   -- The Princess Bride
 


 --
 I could give you my word as a Spaniard.
 No good. I've known too many Spaniards.
 -- The Princess Bride

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]






--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507204 - /jakarta/commons/proper/commons-parent/trunk/pom.xml

2007-02-13 Thread dennisl

Author: dennisl
Date: Tue Feb 13 12:38:19 2007
New Revision: 507204

URL: http://svn.apache.org/viewvc?view=revrev=507204
Log:
Add javadoc, jxr, surefire and jdepend reports.

Modified:
jakarta/commons/proper/commons-parent/trunk/pom.xml

Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/commons-parent/trunk/pom.xml?view=diffrev=507204r1=507203r2=507204
==
--- jakarta/commons/proper/commons-parent/trunk/pom.xml (original)
+++ jakarta/commons/proper/commons-parent/trunk/pom.xml Tue Feb 13 12:38:19 2007
@@ -179,6 +179,20 @@
 plugins
   plugin
 groupIdorg.apache.maven.plugins/groupId
+artifactIdmaven-javadoc-plugin/artifactId
+configuration 
+  aggregatetrue/aggregate
+/configuration 
+  /plugin
+  plugin
+groupIdorg.apache.maven.plugins/groupId
+artifactIdmaven-jxr-plugin/artifactId
+configuration 
+  aggregatetrue/aggregate
+/configuration 
+  /plugin
+  plugin
+groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-site-plugin/artifactId
 configuration
   !-- Exclude the navigation file for Maven 1 sites
@@ -188,6 +202,15 @@
 xdocnavigation.xml,changes.xml/xdoc
   /moduleExcludes
 /configuration
+  /plugin
+  plugin
+groupIdorg.apache.maven.plugins/groupId
+artifactIdmaven-surefire-report-plugin/artifactId
+  /plugin
+  plugin
+groupIdorg.codehaus.mojo/groupId
+artifactIdjdepend-maven-plugin/artifactId
+version2.0-beta-1/version
   /plugin
 /plugins
   /reporting



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507212 - in /jakarta/commons/proper/configuration/trunk: src/java/org/apache/commons/configuration/reloading/ src/test/org/apache/commons/configuration/reloading/ xdocs/

Author: oheger
Date: Tue Feb 13 12:54:15 2007
New Revision: 507212

URL: http://svn.apache.org/viewvc?view=revrev=507212
Log:
CONFIGURATION-237: Added ManagedReloadingStrategy. Thanks to Nicolas de Loof

Added:

jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/reloading/ManagedReloadingStrategy.java
   (with props)

jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/reloading/ManagedReloadingStrategyMBean.java
   (with props)

jakarta/commons/proper/configuration/trunk/src/test/org/apache/commons/configuration/reloading/TestManagedReloadingStrategy.java
   (with props)
Modified:
jakarta/commons/proper/configuration/trunk/xdocs/changes.xml
jakarta/commons/proper/configuration/trunk/xdocs/howto_filebased.xml

Added: 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/reloading/ManagedReloadingStrategy.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/reloading/ManagedReloadingStrategy.java?view=autorev=507212
==
--- 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/reloading/ManagedReloadingStrategy.java
 (added)
+++ 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/reloading/ManagedReloadingStrategy.java
 Tue Feb 13 12:54:15 2007
@@ -0,0 +1,94 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.commons.configuration.reloading;
+
+import org.apache.commons.configuration.FileConfiguration;
+import org.apache.commons.logging.Log;
+import org.apache.commons.logging.LogFactory;
+
+/**
+ * A strategy to reload configuration based on management requests. Designed 
for
+ * JMX management.
+ *
+ * @author Nicolas De loof
+ */
+public class ManagedReloadingStrategy implements ReloadingStrategy,
+ManagedReloadingStrategyMBean
+{
+/** The logger. */
+private Log log = LogFactory.getLog(ManagedReloadingStrategy.class);
+
+/** Stores a reference to the associated configuration. */
+private FileConfiguration configuration;
+
+/** A flag whether a reload is required. */
+private boolean reloadingRequired;
+
+/**
+ * @see org.apache.commons.configuration.reloading.ReloadingStrategy#init()
+ */
+public void init()
+{
+return;
+}
+
+/**
+ * @see 
org.apache.commons.configuration.reloading.ReloadingStrategy#reloadingPerformed()
+ */
+public void reloadingPerformed()
+{
+reloadingRequired = false;
+}
+
+/**
+ * Checks whether reloading is required. This implementation checks whether
+ * the coderefresh()/code method has been invokded.
+ *
+ * @return a flag whether reloading is required
+ * @see 
org.apache.commons.configuration.reloading.ReloadingStrategy#reloadingRequired()
+ */
+public boolean reloadingRequired()
+{
+return reloadingRequired;
+}
+
+/**
+ * Sets the associated configuration.
+ *
+ * @param configuration the associated configuration
+ */
+public void setConfiguration(FileConfiguration configuration)
+{
+this.configuration = configuration;
+}
+
+/**
+ * Tells this strategy that the monitored configuration file should be
+ * refreshed. This method will typically be called from outside (through an
+ * exposed MBean) on behalf of an administrator.
+ *
+ * @see 
org.apache.commons.configuration.reloading.ManagedReloadingStrategyMBean#refresh()
+ */
+public void refresh()
+{
+log.info(Reloading configuration.);
+this.reloadingRequired = true;
+// force reloading
+configuration.isEmpty();
+}
+}

Propchange: 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/reloading/ManagedReloadingStrategy.java
--
svn:eol-style = native

Propchange:

[jira] Resolved: (CONFIGURATION-237) Contrib : managed reloading strategy

2007-02-13 Thread Oliver Heger (JIRA)


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Heger resolved CONFIGURATION-237.


   Resolution: Fixed
Fix Version/s: (was: 1.5)
   1.4

Patch applied with minor modifications. Thanks very much.

 Contrib : managed reloading strategy
 

 Key: CONFIGURATION-237
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-237
 Project: Commons Configuration
  Issue Type: New Feature
Affects Versions: Nightly Builds
Reporter: nicolas de loof
Priority: Minor
 Fix For: 1.4

 Attachments: CONFIGURATION-237.patch, howto-filebased.patch, 
 ManagedReloadingStrategyTest.java


 This patch adds a reloading strategy based on management request, typically 
 from a JMX console. The Strategy implements a MBean interface so can be 
 exported as a JMX Managed bean with no code change.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (CONFIGURATION-249) save to URLs with a protocol other than file:

2007-02-13 Thread Oliver Heger (JIRA)


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Heger updated CONFIGURATION-249:
---

Fix Version/s: (was: 1.4)
   1.5

 save to URLs with a protocol other than file:
 ---

 Key: CONFIGURATION-249
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-249
 Project: Commons Configuration
  Issue Type: Improvement
Affects Versions: 1.4
Reporter: Anselm Kruis
Priority: Minor
 Fix For: 1.5


 Currently, the save(URL) method from AbstractFileConfiguration only supports 
 file: URLs. 
 Why not support  writing to URLs too? It is as simple like this
   java.net.URLConnection connection = 
 url.openConnection();
   connection.setDoOutput(true);
   connection.setDoInput(false);
   save(connection.getOutputStream());
 I could prepare a patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507219 - /jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DefaultConfigurationBuilder.java

Author: oheger
Date: Tue Feb 13 13:02:09 2007
New Revision: 507219

URL: http://svn.apache.org/viewvc?view=revrev=507219
Log:
Fixed a checkstyle warning

Modified:

jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DefaultConfigurationBuilder.java

Modified: 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DefaultConfigurationBuilder.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DefaultConfigurationBuilder.java?view=diffrev=507219r1=507218r2=507219
==
--- 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DefaultConfigurationBuilder.java
 (original)
+++ 
jakarta/commons/proper/configuration/trunk/src/java/org/apache/commons/configuration/DefaultConfigurationBuilder.java
 Tue Feb 13 13:02:09 2007
@@ -789,9 +789,10 @@
 /**
  * Returns the configuration. This method is called to fetch the
  * configuration from the provider. This implementation will call the
- * inherited
- * code[EMAIL PROTECTED] 
org.apache.commons.configuration.beanutils.DefaultBeanFactory#createBean(Class, 
BeanDeclaration, Object) createBean()}/code
- * method to create a new instance of the configuration class.
+ * inherited code[EMAIL PROTECTED]
+ * 
org.apache.commons.configuration.beanutils.DefaultBeanFactory#createBean(Class, 
BeanDeclaration, Object)
+ * createBean()}/code method to create a new instance of the
+ * configuration class.
  *
  * @param decl the bean declaration with initialization parameters for
  * the configuration



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Congratulations to Craig McClanahan...

2007-02-13 Thread Dennis Lundberg


...for making it into Java Developers Journal's
  The Top 150 i-Technology Heroes of Today and Yesteryear

Read all about it here:
  http://java.sys-con.com/read/33.htm

--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507231 - /jakarta/commons/proper/fileupload/branches/b1_2/pom.xml

Author: jochen
Date: Tue Feb 13 13:15:09 2007
New Revision: 507231

URL: http://svn.apache.org/viewvc?view=revrev=507231
Log:
Added the rat-maven-plugin.

Modified:
jakarta/commons/proper/fileupload/branches/b1_2/pom.xml

Modified: jakarta/commons/proper/fileupload/branches/b1_2/pom.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/branches/b1_2/pom.xml?view=diffrev=507231r1=507230r2=507231
==
--- jakarta/commons/proper/fileupload/branches/b1_2/pom.xml (original)
+++ jakarta/commons/proper/fileupload/branches/b1_2/pom.xml Tue Feb 13 13:15:09 
2007
@@ -295,6 +295,10 @@
   minSeverityinfo/minSeverity
 /configuration
   /plugin
+  plugin
+groupIdorg.codehaus.mojo/groupId
+artifactIdrat-maven-plugin/artifactId
+  /plugin
 /plugins
   /reporting
 /project



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507232 - /jakarta/commons/proper/configuration/trunk/RELEASE-NOTES.txt

Author: oheger
Date: Tue Feb 13 13:20:43 2007
New Revision: 507232

URL: http://svn.apache.org/viewvc?view=revrev=507232
Log:
Updated release notes

Modified:
jakarta/commons/proper/configuration/trunk/RELEASE-NOTES.txt

Modified: jakarta/commons/proper/configuration/trunk/RELEASE-NOTES.txt
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/RELEASE-NOTES.txt?view=diffrev=507232r1=507231r2=507232
==
--- jakarta/commons/proper/configuration/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/configuration/trunk/RELEASE-NOTES.txt Tue Feb 13 
13:20:43 2007
@@ -53,14 +53,6 @@
   variable interpolation. So it is possible to refer to a variable in one
   (sub) configuration that is defined in another configuration.
 
-* [CONFIGURATION-234]
-  DefaultConfigurationBuilder now internally uses the standard expression
-  engine for hierarchical configurations. So the dependency to Commons JXPath
-  is no more needed when this class is used. Note that this change has some
-  impact on exist ing code that manually sets properties before the combined
-  configuration is created; this code must now be adapted to the changed
-  syntax of property keys.
-
 * [CONFIGURATION-235]
   Interpolation of non string values did not work when SubsetConfiguration
   was involved. This has now been fixed.
@@ -78,13 +70,6 @@
   CompositeConfiguration.clearProperty() now generates the correct update
   events.
 
-* [CONFIGURATION-242]
-  The configuration returned by HierarchicalConfiguration.subset() performed
-  variable interpolation only in the keys that belong to the subset. Now the
-  parent configuration is searched, too, to resolve the value of the
-  referenced property. This is consistent with the way SubnodeConfiguration
-  works.
-
 * [CONFIGURATION-244]
   The number of dependencies needed for DefaultConfigurationBuilder was reduced
   by letting some of the default configuration providers resolve their classes
@@ -95,7 +80,7 @@
   used version 2.0.2 is reported to be bogus.
 
 * [CONFIGURATION-252]
-  ConfigurationUtils.getFile() now always checks first´whether the passed in
+  ConfigurationUtils.getFile() now always checks first whether the passed in
   file name is absolute. If it is, this file will be returned. This prevents
   that on Unix under certain circumstances absolute file names are interpreted
   as relative ones.
@@ -122,6 +107,10 @@
   HierarchicalConfiguration and some of its sub classes now define a copy
   constructor.
 
+* [CONFIGURATUON-237]
+  With ManagedReloadingStrategy a new reloading strategy for file-based
+  configurations was added that can be triggered through JMX.
+
 * [CONFIGURATION-243]
   Configuration declarations in the configuration definition file for
   DefaultConfigurationBuilder that are marked as optional now support a new
@@ -139,6 +128,29 @@
   error listener at the passed in configuration that generates a runtime
   exception when an error event is received.
 
+CHANGES THAT MIGHT IMPACT EXISTING CODE:
+
+
+* [CONFIGURATION-234]
+  DefaultConfigurationBuilder now internally uses the standard expression
+  engine for hierarchical configurations. So the dependency to Commons JXPath
+  is no more needed when this class is used. Note that this change has some
+  impact on exist ing code that manually sets properties before the combined
+  configuration is created; this code must now be adapted to the changed
+  syntax of property keys.
+
+* [CONFIGURATION-242]
+  The configuration returned by HierarchicalConfiguration.subset() performed
+  variable interpolation only in the keys that belong to the subset. Now the
+  parent configuration is searched, too, to resolve the value of the
+  referenced property. This is consistent with the way SubnodeConfiguration
+  works, but it slightly changes the behavior of interpolation for
+  configurations that are loaded by DefaultConfigurationBuilder and are
+  stored in the resulting CombinedConfiguration under a prefix. If a
+  subset is fetched for this prefix, in version 1.3 variables could be
+  resolved that belong to the same subset. This does not work any more in
+  version 1.4
+
 OTHER CHANGES
 =
 
@@ -152,4 +164,4 @@
 * The dependencies to Commons Collections and Commons Digester are updated to
   use the recent available version. However older versions will still work.
 
-* A pom for maven 2 was added.
\ No newline at end of file
+* A pom for maven 2 was added.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507233 - in /jakarta/commons/proper/configuration/trunk: pom.xml project.xml

Author: oheger
Date: Tue Feb 13 13:23:56 2007
New Revision: 507233

URL: http://svn.apache.org/viewvc?view=revrev=507233
Log:
Added Nicolas De Loof to the list of contributors

Modified:
jakarta/commons/proper/configuration/trunk/pom.xml
jakarta/commons/proper/configuration/trunk/project.xml

Modified: jakarta/commons/proper/configuration/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/pom.xml?view=diffrev=507233r1=507232r2=507233
==
--- jakarta/commons/proper/configuration/trunk/pom.xml (original)
+++ jakarta/commons/proper/configuration/trunk/pom.xml Tue Feb 13 13:23:56 2007
@@ -176,6 +176,12 @@
   email[EMAIL PROTECTED]/email
   organizationInfoblu S.p.A/organization
 /contributor
+
+contributor
+  nameNicolas De Loof/name
+  email[EMAIL PROTECTED]/email
+  organizationcapgemini/organization
+/contributor
 /contributors
 
   !-- Lang should depend on very little --

Modified: jakarta/commons/proper/configuration/trunk/project.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/configuration/trunk/project.xml?view=diffrev=507233r1=507232r2=507233
==
--- jakarta/commons/proper/configuration/trunk/project.xml (original)
+++ jakarta/commons/proper/configuration/trunk/project.xml Tue Feb 13 13:23:56 
2007
@@ -212,6 +212,12 @@
   organizationInfoblu S.p.A/organization
 /contributor
 
+contributor
+  nameNicolas De Loof/name
+  email[EMAIL PROTECTED]/email
+  organizationcapgemini/organization
+/contributor
+
   /contributors
 
   dependencies



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Commons Configuration] using setProperty for data element on XML plist

2007-02-13 Thread Oliver Heger


Raymond, Brian wrote:
I have been banging my head against the wall for hours trying to write a 
data/ element back into an OSX XML plist file. I use the following to 
successfully read the element:


byte[] tmpByte = (byte[])settings.getProperty(node.name)

I then modify it but I cannot for the life of me figure out how to cast 
it and write it back into the file using setProperty(). I'm at the point 
where I Base64 encode it and write it out as a string but I cannot get 
it back into data.  I have looked through the junit tests, javadocs 
and online and the closest thing I found was a nested class with an 
addDataValue() method that looks like it's built for this but it warns 
that it's for internal use by the digester.


Thanks for reading, if anyone can provide a pointer I would be grateful.

Thanks,

- Brian


Brian,

I haven't used XMLPropertyListConfiguration myself. But from a short 
glance at the code I fear that there could be a bug related to the 
handling of arrays. What exactly is the result when you call 
setProperty() with the modified byte[]?


Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507236 - in /jakarta/commons/proper/fileupload/branches/b1_2: pom.xml src/changes/changes.xml xdocs/index.xml

Author: jochen
Date: Tue Feb 13 13:33:38 2007
New Revision: 507236

URL: http://svn.apache.org/viewvc?view=revrev=507236
Log:
Creating 1.2rc4.

Modified:
jakarta/commons/proper/fileupload/branches/b1_2/pom.xml
jakarta/commons/proper/fileupload/branches/b1_2/src/changes/changes.xml
jakarta/commons/proper/fileupload/branches/b1_2/xdocs/index.xml

Modified: jakarta/commons/proper/fileupload/branches/b1_2/pom.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/branches/b1_2/pom.xml?view=diffrev=507236r1=507235r2=507236
==
--- jakarta/commons/proper/fileupload/branches/b1_2/pom.xml (original)
+++ jakarta/commons/proper/fileupload/branches/b1_2/pom.xml Tue Feb 13 13:33:38 
2007
@@ -27,7 +27,7 @@
   modelVersion4.0.0/modelVersion
   groupIdcommons-fileupload/groupId
   artifactIdcommons-fileupload/artifactId
-  version1.2rc3/version
+  version1.2/version
   nameFileUpload/name
   description
 The FileUpload component provides a simple yet flexible means of adding 
support for multipart

Modified: 
jakarta/commons/proper/fileupload/branches/b1_2/src/changes/changes.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/branches/b1_2/src/changes/changes.xml?view=diffrev=507236r1=507235r2=507236
==
--- jakarta/commons/proper/fileupload/branches/b1_2/src/changes/changes.xml 
(original)
+++ jakarta/commons/proper/fileupload/branches/b1_2/src/changes/changes.xml Tue 
Feb 13 13:33:38 2007
@@ -41,7 +41,7 @@
   /properties
 
   body
-   release version=1.2 date=Not yet released
+   release version=1.2 date=2007-02-13
 
   action dev=jochen type=fix due-to=Aaron Freeman
due-to-email=[EMAIL PROTECTED]

Modified: jakarta/commons/proper/fileupload/branches/b1_2/xdocs/index.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/branches/b1_2/xdocs/index.xml?view=diffrev=507236r1=507235r2=507236
==
--- jakarta/commons/proper/fileupload/branches/b1_2/xdocs/index.xml (original)
+++ jakarta/commons/proper/fileupload/branches/b1_2/xdocs/index.xml Tue Feb 13 
13:33:38 2007
@@ -58,6 +58,14 @@
 section name=Downloading
 subsection name='Full Releases'
   p
+strongFileUpload 2/strong - 13 February 2007
+ul
+  liDownload the binary and source distributions from a mirror 
site
+a 
href='http://jakarta.apache.org/site/downloads/downloads_commons-fileupload.cgi'here/a
+  /li
+/ul
+  /p
+  p
 strongFileUpload 1.1.1/strong - 08 June 2006
 ul
   liDownload the binary and source distributions from a mirror 
site



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507253 - /jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/MathException.java

2007-02-13 Thread luc

Author: luc
Date: Tue Feb 13 14:06:30 2007
New Revision: 507253

URL: http://svn.apache.org/viewvc?view=revrev=507253
Log:
allow using locales with different variants

Modified:

jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/MathException.java

Modified: 
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/MathException.java
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/MathException.java?view=diffrev=507253r1=507252r2=507253
==
--- 
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/MathException.java
 (original)
+++ 
jakarta/commons/proper/math/trunk/src/java/org/apache/commons/math/MathException.java
 Tue Feb 13 14:06:30 2007
@@ -86,7 +86,7 @@
 
ResourceBundle.getBundle(org.apache.commons.math.MessagesResources, locale);
 }
 
-if (cachedResources.getLocale().equals(locale)) {
+if 
(cachedResources.getLocale().getLanguage().equals(locale.getLanguage())) {
 // the value of the resource is the translated string
 return cachedResources.getString(s);
 }



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (EMAIL-6) [email] Errors when sending MultiPartEmail with another email as an attachment


[ 
https://issues.apache.org/jira/browse/EMAIL-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472922
 ] 

Ben Speakmon commented on EMAIL-6:
--

My current thinking on this:

I'm not convinced that it's useful to support attaching one subclass of Email 
to another subclass -- that is, the original report creates an HtmlEmail and 
then wants to attach that to a MultiPartEmail. The current design of 
commons-email would make this very tricky, but aside from that I don't see the 
general usefulness of doing so.

One case where I do see a use for this would be when the user wants to attach a 
MimeMessage he got from somewhere (like a server or a filestore) to a subclass 
of Email. This would mean adding MultiPartEmail.addMimeMessage() methods which 
would then be attached like the current addPart() methods. (We'd have to have 
different names, since MimeMessage doesn't share a common interface ancestor 
with MimeMultipart.) I'll look into this option.

 [email] Errors when sending MultiPartEmail with another email as an attachment
 --

 Key: EMAIL-6
 URL: https://issues.apache.org/jira/browse/EMAIL-6
 Project: Commons Email
  Issue Type: Bug
Affects Versions: 1.0
 Environment: Operating System: other
 Platform: Other
Reporter: Dave Cherkassky
 Attachments: MultiPartEmailTest.java.patch


 Take a look at the code below:
 if( debugMode ) {
   if( logger.isInfoEnabled() ) {
 logger.info( DEBUG mode is on.  Sending email to  + debugEmailAddress );
   }
   MultiPartEmail debugEmail = new MultiPartEmail();
   if( logger.isDebugEnabled() ) {
 debugEmail.setDebug( true );
   }
   debugEmail.setBounceAddress( debugEmailAddress );
   debugEmail.setFrom( debugEmailAddress );
   debugEmail.addReplyTo( debugEmailAddress );
   debugEmail.addTo( debugEmailAddress );
   debugEmail.setSubject( Test Message:  + email.getSubject() );
   debugEmail.setMsg( The email manager is operating in test mode.   +
 Attached is a message it would have sent had it been running for real. 
 );
   debugEmail.addPart( new MimeMultipart( 
   new MimePartDataSource( email.getMimeMessage() ) ) );
   debugEmail.setMailSession( emailSession );
   messageId = debugEmail.send();
 }
 I get the following exception when I call debugEmail.send():
 2006-03-12 09:07:01,140 [  main] INFO 
 com.djinnsoft.jade.email.EmailManager: DEBUG mode is on.  Sending email to
 [EMAIL PROTECTED]
 2006-03-12 09:07:01,640 [  main] WARN 
 com.djinnsoft.jade.email.EmailManager: Error emailing sent item 235: 
 Sending
 the email to the following server failed : null:25
 javax.mail.SendFailedException: Sending failed;
  nested exception is:
   javax.mail.MessagingException: IOException while sending message;
  nested exception is:
   java.io.IOException: text/plain DataContentHandler requires String object,
 was given object of type class javax.mail.internet.MimeMultipart
   at javax.mail.Transport.send0(Transport.java:219)
   at javax.mail.Transport.send(Transport.java:81)
   at org.apache.commons.mail.Email.sendMimeMessage(Email.java:863)
   at org.apache.commons.mail.Email.send(Email.java:898)
   at 
 com.djinnsoft.jade.email.EmailManager.processMailing(EmailManager.java:1205)
 (line 1205 corresponds to messageId = debugEmail.send(); in my code)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta-commons Wiki] Update of Email by BenSpeakmon

2007-02-13 Thread Apache Wiki

Dear Wiki user,

You have subscribed to a wiki page or wiki category on Jakarta-commons Wiki 
for change notification.

The following page has been changed by BenSpeakmon:
http://wiki.apache.org/jakarta-commons/Email

The comment on the change is:
Added list of current open issues with status and my recommendation.

--
  
  || http://jakarta.apache.org/commons/email/images/email-logo-white.png || 
[http://jakarta.apache.org/commons/email/ Commons-Email] aims to provide a API 
for sending email. It is built on top of the JavaMail API, which it aims to 
simplify.[[BR]] A lot of information is available on the 
[http://jakarta.apache.org/commons/email/ Commons-Email website].[[BR]] If you 
don't find the information you need you can always contact us using one of the 
[http://jakarta.apache.org/site/mail2.html#Commons mailing lists]. ||
  
- = Project Status =
+ = (Official) Project Status =
  
  The current status (updated 11/2006) is available through SVN 
[http://svn.apache.org/repos/asf/jakarta/commons/proper/email/trunk/STATUS.html 
here].
+ 
+ 
+ 
+ = Open issues (last updated Feb 13 2007) =
+ 
+ These are the currently open issues organized according to category.
+ 
+ == Character set fixes/support ==
+ 
+ email 1.0 provided limited support for different charsets, and it's generated 
four issues. 
+ 
+ [https://issues.apache.org/jira/browse/EMAIL-1 EMAIL-1]: Default email 
charset not used for text content. A patch has been uploaded that defines three 
different cases for this behavior and tests/fixes each.
+ 
+ [https://issues.apache.org/jira/browse/EMAIL-54 EMAIL-54]: Propose a new 
Charset enum. The current patch uses the JDK 1.4 java.nio.charset.Charset class 
to validate user-supplied charset names. This removes the need for a separate 
enumeration of supported classes and greatly reduces the headache of 
maintaining the support as the JVM continues to evolve. This also incorporates 
fixes for two other open issues:
+  * [https://issues.apache.org/jira/browse/EMAIL-25 EMAIL-25]: Can't set 
charset for a single address.
+  * [https://issues.apache.org/jira/browse/EMAIL-14 EMAIL-14]: Support a 
couple specific charsets.
+ 
+ == Bug fixes ==
+ 
+ email 1.0 doesn't handle HTML embedding or attachments correctly. This is 
really bad, and is reason enough for a 1.1 release.
+ 
+ [https://issues.apache.org/jira/browse/EMAIL-50 EMAIL-50]: HTML mail doesn't 
display correctly (the issue says in Outlook 2000, but the display fails on 
every common mail client I tried). It's not an Outlook-specific error. A patch 
is available that fixes this and has been tested on several different clients; 
also, the new patch adheres properly to the MIME specs in RFC 2045-2049 where 
email 1.0 did not. The fix also resolves two other open issues:
+  * [https://issues.apache.org/jira/browse/EMAIL-28 EMAIL-28]: HTML 
attachments don't work correctly.
+  * [https://issues.apache.org/jira/browse/EMAIL-52 EMAIL-52]: Don't embed the 
same URL multiple times in the same email.
+ 
+ == New feature requests ==
+ 
+ [https://issues.apache.org/jira/browse/EMAIL-35 EMAIL-35]: Allow DataSources 
to be directly embedded in HtmlEmails. Patch available.
+ 
+ [https://issues.apache.org/jira/browse/EMAIL-56 EMAIL-56]: Support creating 
Email subclasses from MimeMessages.
+ 
+ ''(BenSpeakmon) One of the MimeMessage constructors in JavaMail (both 1.3 and 
1.4) already does this, BTW. I'm not sure this is something that falls within 
commons-email's scope. The commons-email API, I think, is for the common cases 
where you just want to build and send an email without needing the power (or 
complexity) of JavaMail. If you're already pulling messages from an email 
server, I don't know why you wouldn't just use JavaMail for manipulating it -- 
the power and complexity is just what you need for those kinds of jobs. And it 
doesn't seem worth the trouble to duplicate any of that code in commons-email 
when the existing code works just fine. I'd recommend WONTFIXing this one.''
+ 
+ [https://issues.apache.org/jira/browse/EMAIL-6 EMAIL-6]: Allow attaching one 
subclass of Email to another.
+ 
+ ''(BenSpeakmon) I'm not convinced that it's useful to support attaching one 
subclass of Email to another subclass -- that is, the original report creates 
an HtmlEmail and then wants to attach that to a MultiPartEmail. The current 
design of commons-email would make this very tricky, but aside from that I 
don't see the general usefulness of doing so. One case where I do see a use for 
this would be when the user wants to attach a MimeMessage he got from somewhere 
(like a server or a filestore) to a subclass of Email. This would mean adding 
MultiPartEmail.addMimeMessage() methods which would then be attached like the 
current addPart() methods. (We'd have to have different names, since 
MimeMessage doesn't share a common interface ancestor with MimeMultipart.) I'll 
look into

[jira] Commented: (EMAIL-64) Use wiser instead of dumbster for test cases

2007-02-13 Thread Bindul Bhowmik (JIRA)

[
https://issues.apache.org/jira/browse/EMAIL-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472933
]

Bindul Bhowmik commented on EMAIL-64:
-

I have started to move the test cases over to using Wiser. However, I found out
that Wiser is built on Java 1.5. The version of Wiser/SubethaSMTP I am using is
1.0.3. This is the only version available on Maven repositories
(http://repo1.maven.org/maven2/org/subethamail/).

So, the tests run when using a JRE 1.5, or I get a class version error.

Looking at the subetha website, the latest version is 1.1
(http://subethasmtp.tigris.org/servlets/ProjectDocumentList?folderID=7035expandFolder=7035folderID=7624)
but that has not been uploaded to maven yet. The site also lists a JRE 1.4
version of subetha smtp and subetha wiser 1.1
(http://subethasmtp.tigris.org/servlets/ProjectDocumentList?folderID=7624expandFolder=7624folderID=7035),
but that too is not up on maven.

If the license of the tools is fine, could someone add subetha to maven? Or are
we OK living with Java 1.5 as the required compiler for commons-email?

Use wiser instead of dumbster for test cases

Key: EMAIL-64
URL: https://issues.apache.org/jira/browse/EMAIL-64
Project: Commons Email
Issue Type: Improvement
Affects Versions: 1.1
Reporter: Ben Speakmon
Fix For: 1.1

Since the test cases depend on a snapshot of the dead project dumbster, the
tests should be changed to use the wiser test email server instead. Marking
as 1.1 fix since this should get done before 1.1 goes out the door.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507361 - /jakarta/commons/proper/commons-parent/trunk/pom.xml

Author: jochen
Date: Tue Feb 13 18:35:56 2007
New Revision: 507361

URL: http://svn.apache.org/viewvc?view=revrev=507361
Log:
Added the rat-maven-plugins report.

Modified:
jakarta/commons/proper/commons-parent/trunk/pom.xml

Modified: jakarta/commons/proper/commons-parent/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/commons-parent/trunk/pom.xml?view=diffrev=507361r1=507360r2=507361
==
--- jakarta/commons/proper/commons-parent/trunk/pom.xml (original)
+++ jakarta/commons/proper/commons-parent/trunk/pom.xml Tue Feb 13 18:35:56 2007
@@ -212,6 +212,10 @@
 artifactIdjdepend-maven-plugin/artifactId
 version2.0-beta-1/version
   /plugin
+  plugin
+groupIdorg.codehaus.mojo/groupId
+artifactIdrat-maven-plugin/artifactId
+  /plugin
 /plugins
   /reporting
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507375 - /jakarta/commons/proper/fileupload/branches/b1_2/pom.xml

Author: jochen
Date: Tue Feb 13 19:24:25 2007
New Revision: 507375

URL: http://svn.apache.org/viewvc?view=revrev=507375
Log:
Got it finally working to add LICENSE and NOTICE to -sources.jar
and -javadoc.jar, while at the same time building the assemblies.

Modified:
jakarta/commons/proper/fileupload/branches/b1_2/pom.xml

Modified: jakarta/commons/proper/fileupload/branches/b1_2/pom.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/branches/b1_2/pom.xml?view=diffrev=507375r1=507374r2=507375
==
--- jakarta/commons/proper/fileupload/branches/b1_2/pom.xml (original)
+++ jakarta/commons/proper/fileupload/branches/b1_2/pom.xml Tue Feb 13 19:24:25 
2007
@@ -137,68 +137,6 @@
   /archive
 /configuration
   /plugin
-  plugin
-artifactIdmaven-assembly-plugin/artifactId
-configuration
-  descriptors
-descriptorsrc/main/assembly/bin.xml/descriptor
-descriptorsrc/main/assembly/src.xml/descriptor
-  /descriptors
-  tarLongFileModegnu/tarLongFileMode
-/configuration
-  /plugin
-  plugin
-artifactIdmaven-antrun-plugin/artifactId
-executions
-  execution
-idaddLicenseAndNotice/id
-phaseverify/phase
-goals
-  goalrun/goal
-/goals
-configuration
-  tasks
-delete dir=${project.build.directory}/zipDir/
-mkdir dir=${project.build.directory}/zipDir/
-unzip 
src=${project.build.directory}/${project.artifactId}-${project.version}-sources.jar
 dest=${project.build.directory}/zipDir/
-copy todir=${project.build.directory}/zipDir/META-INF
-  fileset dir=${basedir}
-include name=LICENSE.txt/
-include name=NOTICE.txt/
-  /fileset
-/copy
-zip 
destfile=${project.build.directory}/${project.artifactId}-${project.version}-sources.jar
-  fileset dir=${project.build.directory}/zipDir/
-/zip
-delete dir=${project.build.directory}/zipDir/
-mkdir dir=${project.build.directory}/zipDir/
-unzip 
src=${project.build.directory}/${project.artifactId}-${project.version}-javadoc.jar
 dest=${project.build.directory}/zipDir/
-copy todir=${project.build.directory}/zipDir/META-INF
-  fileset dir=${basedir}
-include name=LICENSE.txt/
-include name=NOTICE.txt/
-  /fileset
-/copy
-zip 
destfile=${project.build.directory}/${project.artifactId}-${project.version}-javadoc.jar
-  fileset dir=${project.build.directory}/zipDir/
-/zip
-  /tasks
-/configuration
-  /execution
-/executions
-  /plugin
-  plugin
-artifactIdmaven-gpg-plugin/artifactId
-executions
-  execution
-idsign-artifacts/id
-phaseverify/phase
-goals
-  goalsign/goal
-/goals
-  /execution
-/executions
-  /plugin
 /plugins
   /build
 
@@ -301,4 +239,84 @@
   /plugin
 /plugins
   /reporting
+
+  profiles
+profile
+  idrelease/id
+  build
+plugins
+  plugin
+artifactIdmaven-antrun-plugin/artifactId
+executions
+  execution
+idaddLicenseAndNotice/id
+phaseverify/phase
+goals
+  goalrun/goal
+/goals
+configuration
+  tasks
+delete dir=${project.build.directory}/zipDir/
+mkdir dir=${project.build.directory}/zipDir/
+unzip 
src=${project.build.directory}/${project.artifactId}-${project.version}-sources.jar
 dest=${project.build.directory}/zipDir/
+copy todir=${project.build.directory}/zipDir/META-INF
+  fileset dir=${basedir}
+include name=LICENSE.txt/
+include name=NOTICE.txt/
+  /fileset
+/copy
+zip 
destfile=${project.build.directory}/${project.artifactId}-${project.version}-sources.jar
+  fileset dir=${project.build.directory}/zipDir/
+/zip
+delete dir=${project.build.directory}/zipDir/
+mkdir dir=${project.build.directory}/zipDir/
+unzip 
src=${project.build.directory}/${project.artifactId}-${project.version}-javadoc.jar
 dest=${project.build.directory}/zipDir/
+copy todir=${project.build.directory}/zipDir/META-INF
+

svn commit: r507376 - /jakarta/commons/proper/fileupload/branches/b1_2/xdocs/index.xml

Author: jochen
Date: Tue Feb 13 19:29:22 2007
New Revision: 507376

URL: http://svn.apache.org/viewvc?view=revrev=507376
Log:
Fixed the wrong version number.

Modified:
jakarta/commons/proper/fileupload/branches/b1_2/xdocs/index.xml

Modified: jakarta/commons/proper/fileupload/branches/b1_2/xdocs/index.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/branches/b1_2/xdocs/index.xml?view=diffrev=507376r1=507375r2=507376
==
--- jakarta/commons/proper/fileupload/branches/b1_2/xdocs/index.xml (original)
+++ jakarta/commons/proper/fileupload/branches/b1_2/xdocs/index.xml Tue Feb 13 
19:29:22 2007
@@ -58,7 +58,7 @@
 section name=Downloading
 subsection name='Full Releases'
   p
-strongFileUpload 2/strong - 13 February 2007
+strongFileUpload 1.2/strong - 13 February 2007
 ul
   liDownload the binary and source distributions from a mirror 
site
 a 
href='http://jakarta.apache.org/site/downloads/downloads_commons-fileupload.cgi'here/a



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r505890 - in /jakarta/commons/proper/httpclient/trunk: release_notes.txt src/java/org/apache/commons/httpclient/AutoCloseInputStream.java src/test/org/apache/commons/httpclient/TestStr

2007-02-13 Thread simon.kitching

Perhaps this should have an @since tag added, as it's a new method?

 [EMAIL PROTECTED] wrote: 
 Modified: 
 jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/AutoCloseInputStream.java
 URL: 
 http://svn.apache.org/viewvc/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/AutoCloseInputStream.java?view=diffrev=505890r1=505889r2=505890
 ==
 --- 
 jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/AutoCloseInputStream.java
  (original)
 +++ 
 jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/AutoCloseInputStream.java
  Sun Feb 11 03:25:25 2007
 @@ -131,6 +131,23 @@
  }
  
  /**
 + * Obtains the number of bytes that can be read without blocking.
 + *
 + * @return  the number of bytes available without blocking
 + * @throws IOException in case of a problem
 + */
 +public int available() throws IOException {
 +int a = 0; // not -1
 +
 +if (isReadAllowed()) {
 +a = super.available();
 +// no checkClose() here, available() can't trigger EOF
 +}
 +
 +return a;
 +}
 +


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507379 - /jakarta/commons/proper/fileupload/branches/b1_2/src/site/site.xml

Author: jochen
Date: Tue Feb 13 20:16:50 2007
New Revision: 507379

URL: http://svn.apache.org/viewvc?view=revrev=507379
Log:
Adding the commons-fileupload logo.

Modified:
jakarta/commons/proper/fileupload/branches/b1_2/src/site/site.xml

Modified: jakarta/commons/proper/fileupload/branches/b1_2/src/site/site.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/branches/b1_2/src/site/site.xml?view=diffrev=507379r1=507378r2=507379
==
--- jakarta/commons/proper/fileupload/branches/b1_2/src/site/site.xml (original)
+++ jakarta/commons/proper/fileupload/branches/b1_2/src/site/site.xml Tue Feb 
13 20:16:50 2007
@@ -17,10 +17,16 @@
 --
 project name=FileUpload
   bannerLeft
+nameJakarta Commons/name
+
srchttp://jakarta.apache.org/commons/fileupload/images/jakarta-logo-blue.gif/src
+hrefhttp://jakarta.apache.org/commons/href
+  /bannerLeft
+
+  bannerRight
 nameCommons FileUpload/name
-srchttp://jakarta.apache.org/images/jakarta-logo-blue.gif/src
+srchttp://jakarta.apache.org/commons/fileupload/images/logo.png/src
 hrefhttp://jakarta.apache.org/commons/fileupload/href
-  /bannerLeft
+  /bannerRight
 
   skin
 groupIdorg.apache.commons/groupId



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (EMAIL-64) Use wiser instead of dumbster for test cases


[ 
https://issues.apache.org/jira/browse/EMAIL-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472974
 ] 

Ben Speakmon commented on EMAIL-64:
---

I wouldn't be happy with requiring JDK 1.5 to build, especially since no code 
in email uses 1.5 features (and it should stay that way).

We should get the 1.4-compatible one into maven. We could hold off on changing 
the test cases until the repository change goes through or just have anybody 
who wants to dev on email manually install it in their own repository. Either 
way, I don't want a temporary maven road bump to force another JDK revision for 
building.

 Use wiser instead of dumbster for test cases
 

 Key: EMAIL-64
 URL: https://issues.apache.org/jira/browse/EMAIL-64
 Project: Commons Email
  Issue Type: Improvement
Affects Versions: 1.1
Reporter: Ben Speakmon
 Fix For: 1.1


 Since the test cases depend on a snapshot of the dead project dumbster, the 
 tests should be changed to use the wiser test email server instead. Marking 
 as 1.1 fix since this should get done before 1.1 goes out the door.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507380 - /jakarta/commons/proper/fileupload/branches/b1_2/pom.xml

Author: jochen
Date: Tue Feb 13 20:17:19 2007
New Revision: 507380

URL: http://svn.apache.org/viewvc?view=revrev=507380
Log:
The maven-site-plugin doesn't add static resources. :-(

Modified:
jakarta/commons/proper/fileupload/branches/b1_2/pom.xml

Modified: jakarta/commons/proper/fileupload/branches/b1_2/pom.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/fileupload/branches/b1_2/pom.xml?view=diffrev=507380r1=507379r2=507380
==
--- jakarta/commons/proper/fileupload/branches/b1_2/pom.xml (original)
+++ jakarta/commons/proper/fileupload/branches/b1_2/pom.xml Tue Feb 13 20:17:19 
2007
@@ -249,6 +249,25 @@
 artifactIdmaven-antrun-plugin/artifactId
 executions
   execution
+idcopySiteResources/id
+phasegenerate-resources/phase
+goals
+  goalrun/goal
+/goals
+configuration
+  tasks
+mkdir dir=${project.build.directory}/site/
+copy todir=${project.build.directory}/site
+  fileset dir=xdocs
+include name=**/*.css/
+include name=**/*.gif/
+include name=**/*.png/
+  /fileset
+/copy
+  /tasks
+/configuration
+  /execution
+  execution
 idaddLicenseAndNotice/id
 phaseverify/phase
 goals



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (EMAIL-64) Use wiser instead of dumbster for test cases

2007-02-13 Thread dion gillard (JIRA)


[ 
https://issues.apache.org/jira/browse/EMAIL-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472978
 ] 

dion gillard commented on EMAIL-64:
---

I'm with Ben.

 Use wiser instead of dumbster for test cases
 

 Key: EMAIL-64
 URL: https://issues.apache.org/jira/browse/EMAIL-64
 Project: Commons Email
  Issue Type: Improvement
Affects Versions: 1.1
Reporter: Ben Speakmon
 Fix For: 1.1


 Since the test cases depend on a snapshot of the dead project dumbster, the 
 tests should be changed to use the wiser test email server instead. Marking 
 as 1.1 fix since this should get done before 1.1 goes out the door.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507386 - /jakarta/commons/proper/fileupload/tags/commons-fileupload-1.2rc4/

Author: jochen
Date: Tue Feb 13 20:48:41 2007
New Revision: 507386

URL: http://svn.apache.org/viewvc?view=revrev=507386
Log: (empty)

Added:
jakarta/commons/proper/fileupload/tags/commons-fileupload-1.2rc4/
  - copied from r507385, jakarta/commons/proper/fileupload/branches/b1_2/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (EMAIL-64) Use wiser instead of dumbster for test cases

2007-02-13 Thread Bindul Bhowmik (JIRA)

[
https://issues.apache.org/jira/browse/EMAIL-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472982
]

Bindul Bhowmik commented on EMAIL-64:
-

I agree too, needed to confirm it with others though.

I will attach a patch to the site documentation as well with the patch for the
test cases, stating the same. Talking about which email 1.0 also went out with
a similar restriction, it required Java 1.3, but the test cases required Java
1.4 (see http://jakarta.apache.org/commons/email/building.html).

Coming back to wiser on maven. I don't believe wiser releases to maven yet (see
the mail thread at http://www.subethamail.org/se/archive_msg.jsp?msgId=7577).
The only version of subetha I found on a maven repository is the 1.0.3
(compiled with Java 1.5) and they have had 3 releases since. I guess someone
else put it up on the repository.

Use wiser instead of dumbster for test cases

Key: EMAIL-64
URL: https://issues.apache.org/jira/browse/EMAIL-64
Project: Commons Email
Issue Type: Improvement
Affects Versions: 1.1
Reporter: Ben Speakmon
Fix For: 1.1

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Release commons-fileupload 1.2 (4th attempt)

2007-02-13 Thread Jochen Wiedmann


Hi,

this is going to kill me, but I'd like to call for a release of
commons-fileupload 1.2 once more. Commons-fileupload-1.2rc4 is
available from

   http://people.apache.org/~jochen/commons-fileupload/dist

The generated site is at

   http://people.apache.org/~jochen/commons-fileupload/dist

The SVN tag is

   commons-fileupload-1.2rc4

Compared to rc3, the following things have been changed:

* The LICENSE.txt and NOTICE.txt files are now added to all jar files.
 (They had been added before, but been overwritten when the assemblies
 have been created.)
* A workaround for a bug in the maven-site-plugin has been added.
 This bug prevented static resources being added. In particular, the
 logo of the commons-fileupload project was missing.
* The RAT report is now added to the projects reports.
* The clirr report is now also added to the project reports. (No idea
 why this wasn't the case before.)

Thanks,

Jochen


[ ] +1
[ ] =0
[ ] -1


--
How fast can a year go? As fast as your childs first year.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (EMAIL-62) [email] Build patches to enforce source 1.4 and target 1.4 when compiling

2007-02-13 Thread dion gillard (JIRA)


[ 
https://issues.apache.org/jira/browse/EMAIL-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472986
 ] 

dion gillard commented on EMAIL-62:
---

Does anyone know why we're patching a Maven-generated build.xml file instead of 
just regenerating it?

Doesn't the maven ant plugin generate a build file with the correct javac task 
attributes?

 [email] Build patches to enforce source 1.4 and target 1.4 when compiling
 -

 Key: EMAIL-62
 URL: https://issues.apache.org/jira/browse/EMAIL-62
 Project: Commons Email
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Ben Speakmon
 Fix For: 1.1

 Attachments: build.xml.patch, project.properties, 
 project.properties.patch


 Maven and Ant patches. Ant patch suppresses spurious 1.5 type safety warnings 
 when building commons-email on JDK = 1.5.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (EMAIL-62) [email] Build patches to enforce source 1.4 and target 1.4 when compiling


[ 
https://issues.apache.org/jira/browse/EMAIL-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472996
 ] 

Ben Speakmon commented on EMAIL-62:
---

I didn't know how to generate a build.xml from maven at the time. I have no 
idea if it would work given a correct project (or pom). 

I have zero objection to regenerating it.

 [email] Build patches to enforce source 1.4 and target 1.4 when compiling
 -

 Key: EMAIL-62
 URL: https://issues.apache.org/jira/browse/EMAIL-62
 Project: Commons Email
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Ben Speakmon
 Fix For: 1.1

 Attachments: build.xml.patch, project.properties, 
 project.properties.patch


 Maven and Ant patches. Ant patch suppresses spurious 1.5 type safety warnings 
 when building commons-email on JDK = 1.5.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: m2 groupIds


What in such a scenario :

My project depends commons-xxx-1.2, relocated at org.apache.commons.xxx-1.2
My pom get transitive commons-xxx-1.1

If I DON't update my POM maven2 will find the relocated artifact and exclude
1.1 - that's fine

If 1.1 has no relocated POM, and if I update my POM, maven2 will get both
1.1 and 1.2 as they will not be detected as same artifact

This mean a relocated POM for all oldest release is required to avoid
duplicated jars in classpath.

(am I wrong ?)



2007/2/13, Carlos Sanchez [EMAIL PROTECTED]:


scenario 3 is with no relocation pom at all, so users get involved by
having to explicitly change the groupId

On 2/13/07, nicolas de loof [EMAIL PROTECTED] wrote:
 I don't understand the distinction you make between scenario 1 and 3 :

 if new release use a relocation pom under commons-xxx and DOESN'T deploy
a
 jar under this group
 - maven2 users will get relocated artifact + a warning to update
 dependencies
 - maven1 users will not get the new version, may ask for it or only
found
 the POM and will update dependencies

 am I wrong ?

 Nico.



 2007/2/13, Carlos Sanchez [EMAIL PROTECTED]:
 
  oh there's a 3rd option that I even like more
 
  3) make new releases in new groupid, no relocations at all
  + easiest ;)
  + users trying to upgrade will need to know that the groupId has
  changed and act by themselves, so they will be involved, and in case
  of classpath problems they will know what has changed
  - it'd be better to wait until a major/minor release so users can get
  bugfixes easily
 
 
  On 2/13/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
   you can change the old poms to relocate to a new location as long as
   the new location has the same old jars and poms (just groupId
change).
   IIRC your case was different.
  
   So, I' see two options for relocation:
  
   1) when new version is out with new groupId add relocation pom in
old
   location just for that new version.
+ Users updating version in old location will get a warning
+ easy to do
 - users may end having old versions and new versions in the
   classpath, that they would have to solve with exclusions
  
   2) relocate all versions to new groupId
+ all users will only notice the warnings when using old group
+ no classpath problems in builds from scratch
- harder to implement, will need to write some code
- people with commons artifacts cached (almost everybody) will
   experience same problems as in 1, possibly getting two versions in
the
   classpath
  
   I'd stick with 1) changing old releases scares me ;) and still
doesn't
   guarantee trouble free upgrades
  
  
  
   On 2/13/07, Jörg Schaible [EMAIL PROTECTED]
wrote:
you cannot change the old POMs anymore, in that case this
description
  is obsolete. The only valid option is to use the new groupId with a
new
  release and provide for this new release a relocation POM at the
former
  location. This was Carlos' advice after a two week hassle to do such a
  transition with XStream.
   
- Jörg
   
   
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
   
   
  
  
   --
   I could give you my word as a Spaniard.
   No good. I've known too many Spaniards.
-- The Princess Bride
  
 
 
  --
  I could give you my word as a Spaniard.
  No good. I've known too many Spaniards.
  -- The Princess Bride
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 



--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: m2 groupIds


right a relocate pom for ALL versions is required to avoid duplication
on classpath
BUT as I said almost everybody will have cached previous versions of
commons so they won't see the relocation until they delete local repo
and the poms with relocation info get downloaded.

On 2/13/07, nicolas de loof [EMAIL PROTECTED] wrote:

What in such a scenario :

My project depends commons-xxx-1.2, relocated at org.apache.commons.xxx-1.2
My pom get transitive commons-xxx-1.1

If I DON't update my POM maven2 will find the relocated artifact and exclude
1.1 - that's fine

If 1.1 has no relocated POM, and if I update my POM, maven2 will get both
1.1 and 1.2 as they will not be detected as same artifact

This mean a relocated POM for all oldest release is required to avoid
duplicated jars in classpath.

 (am I wrong ?)



2007/2/13, Carlos Sanchez [EMAIL PROTECTED]:

 scenario 3 is with no relocation pom at all, so users get involved by
 having to explicitly change the groupId

 On 2/13/07, nicolas de loof [EMAIL PROTECTED] wrote:
  I don't understand the distinction you make between scenario 1 and 3 :
 
  if new release use a relocation pom under commons-xxx and DOESN'T deploy
 a
  jar under this group
  - maven2 users will get relocated artifact + a warning to update
  dependencies
  - maven1 users will not get the new version, may ask for it or only
 found
  the POM and will update dependencies
 
  am I wrong ?
 
  Nico.
 
 
 
  2007/2/13, Carlos Sanchez [EMAIL PROTECTED]:
  
   oh there's a 3rd option that I even like more
  
   3) make new releases in new groupid, no relocations at all
   + easiest ;)
   + users trying to upgrade will need to know that the groupId has
   changed and act by themselves, so they will be involved, and in case
   of classpath problems they will know what has changed
   - it'd be better to wait until a major/minor release so users can get
   bugfixes easily
  
  
   On 2/13/07, Carlos Sanchez [EMAIL PROTECTED] wrote:
you can change the old poms to relocate to a new location as long as
the new location has the same old jars and poms (just groupId
 change).
IIRC your case was different.
   
So, I' see two options for relocation:
   
1) when new version is out with new groupId add relocation pom in
 old
location just for that new version.
 + Users updating version in old location will get a warning
 + easy to do
  - users may end having old versions and new versions in the
classpath, that they would have to solve with exclusions
   
2) relocate all versions to new groupId
 + all users will only notice the warnings when using old group
 + no classpath problems in builds from scratch
 - harder to implement, will need to write some code
 - people with commons artifacts cached (almost everybody) will
experience same problems as in 1, possibly getting two versions in
 the
classpath
   
I'd stick with 1) changing old releases scares me ;) and still
 doesn't
guarantee trouble free upgrades
   
   
   
On 2/13/07, Jörg Schaible [EMAIL PROTECTED]
 wrote:
 you cannot change the old POMs anymore, in that case this
 description
   is obsolete. The only valid option is to use the new groupId with a
 new
   release and provide for this new release a relocation POM at the
 former
   location. This was Carlos' advice after a two week hassle to do such a
   transition with XStream.

 - Jörg


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:
 [EMAIL PROTECTED]


   
   
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride
   
  
  
   --
   I could give you my word as a Spaniard.
   No good. I've known too many Spaniards.
   -- The Princess Bride
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 


 --
 I could give you my word as a Spaniard.
 No good. I've known too many Spaniards.
 -- The Princess Bride

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]






--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: m2 groupIds

2007-02-13 Thread Jörg Schaible

Hi Carlos,

Carlos Sanchez wrote on Tuesday, February 13, 2007 7:29 PM:

 you can change the old poms to relocate to a new location as long as
 the new location has the same old jars and poms (just groupId
 change). IIRC your case was different. 
 
 So, I' see two options for relocation:
 
 1) when new version is out with new groupId add relocation pom in old
 location just for that new version.
  + Users updating version in old location will get a warning  + easy
   to do - users may end having old versions and new versions in the
 classpath, that they would have to solve with exclusions
 
 2) relocate all versions to new groupId
  + all users will only notice the warnings when using old group
  + no classpath problems in builds from scratch
  - harder to implement, will need to write some code
  - people with commons artifacts cached (almost everybody) will
 experience same problems as in 1, possibly getting two versions in
 the classpath 

I don't know whether I should laugh or cry because you offered option 2 at 
all. I took option 2 and adjusted all the old releases of XStream on the 
Codehaus repo, but they do not get synced to the public repo, since the space 
for the relocation POMs is already occupied by the old files. It was you who 
said, nothing can be done about this. Why should the synchronization of the 
Apache repo be different to the one of Codehaus?

- Jörg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: m2 groupIds


According to this, when relocation projectX for new release N+1

option 1 : making dependency to oldGroupId:N+1 will work, but making
dependency to newGroupId:N+1 will introduce duplicate jars issues if other
dependencies introduce transitive-dependency to oldGroupId:N

option 2 : relocating all POM will fail du to proxies caching / mirror /
sync issues and others, so will get duplicate jars issues

option 3 : same as 1

All options introduce duplicate jars issues.

The only solution I can find should be to have some meta-data in the POM to
refer the old groupId, so that maven nows that newGroupId:x is the same
artifact as oldGroupId:x


2007/2/14, Jörg Schaible [EMAIL PROTECTED]:


Hi Carlos,

Carlos Sanchez wrote on Tuesday, February 13, 2007 7:29 PM:

 you can change the old poms to relocate to a new location as long as
 the new location has the same old jars and poms (just groupId
 change). IIRC your case was different.

 So, I' see two options for relocation:

 1) when new version is out with new groupId add relocation pom in old
 location just for that new version.
  + Users updating version in old location will get a warning  + easy
   to do - users may end having old versions and new versions in the
 classpath, that they would have to solve with exclusions

 2) relocate all versions to new groupId
  + all users will only notice the warnings when using old group
  + no classpath problems in builds from scratch
  - harder to implement, will need to write some code
  - people with commons artifacts cached (almost everybody) will
 experience same problems as in 1, possibly getting two versions in
 the classpath

I don't know whether I should laugh or cry because you offered option 2
at all. I took option 2 and adjusted all the old releases of XStream on the
Codehaus repo, but they do not get synced to the public repo, since the
space for the relocation POMs is already occupied by the old files. It was
you who said, nothing can be done about this. Why should the synchronization
of the Apache repo be different to the one of Codehaus?

- Jörg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: m2 groupIds


iirc you have very different jars in the two groupids, that's not
relocation, that would actually change the binaries for users

On 2/13/07, Jörg Schaible [EMAIL PROTECTED] wrote:

Hi Carlos,

Carlos Sanchez wrote on Tuesday, February 13, 2007 7:29 PM:

 you can change the old poms to relocate to a new location as long as
 the new location has the same old jars and poms (just groupId
 change). IIRC your case was different.

 So, I' see two options for relocation:

 1) when new version is out with new groupId add relocation pom in old
 location just for that new version.
  + Users updating version in old location will get a warning  + easy
   to do - users may end having old versions and new versions in the
 classpath, that they would have to solve with exclusions

 2) relocate all versions to new groupId
  + all users will only notice the warnings when using old group
  + no classpath problems in builds from scratch
  - harder to implement, will need to write some code
  - people with commons artifacts cached (almost everybody) will
 experience same problems as in 1, possibly getting two versions in
 the classpath

I don't know whether I should laugh or cry because you offered option 2 at 
all. I took option 2 and adjusted all the old releases of XStream on the Codehaus repo, 
but they do not get synced to the public repo, since the space for the relocation POMs is 
already occupied by the old files. It was you who said, nothing can be done about this. 
Why should the synchronization of the Apache repo be different to the one of Codehaus?

- Jörg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: m2 groupIds


On 2/13/07, nicolas de loof [EMAIL PROTECTED] wrote:

According to this, when relocation projectX for new release N+1

option 1 : making dependency to oldGroupId:N+1 will work, but making
dependency to newGroupId:N+1 will introduce duplicate jars issues if other
dependencies introduce transitive-dependency to oldGroupId:N


iirc making dependency to oldGroupId:N+1 won't work because maven
internally transforms it to newGroupId:N+1, so no difference



option 2 : relocating all POM will fail du to proxies caching / mirror /
sync issues and others, so will get duplicate jars issues

option 3 : same as 1

All options introduce duplicate jars issues.


yes, so 3 would involve the user and when something breaks it won't be
magically



The only solution I can find should be to have some meta-data in the POM to
refer the old groupId, so that maven nows that newGroupId:x is the same
artifact as oldGroupId:x


Already in jira, no progress yet
http://jira.codehaus.org/browse/MNG-2316




2007/2/14, Jörg Schaible [EMAIL PROTECTED]:

 Hi Carlos,

 Carlos Sanchez wrote on Tuesday, February 13, 2007 7:29 PM:

  you can change the old poms to relocate to a new location as long as
  the new location has the same old jars and poms (just groupId
  change). IIRC your case was different.
 
  So, I' see two options for relocation:
 
  1) when new version is out with new groupId add relocation pom in old
  location just for that new version.
   + Users updating version in old location will get a warning  + easy
to do - users may end having old versions and new versions in the
  classpath, that they would have to solve with exclusions
 
  2) relocate all versions to new groupId
   + all users will only notice the warnings when using old group
   + no classpath problems in builds from scratch
   - harder to implement, will need to write some code
   - people with commons artifacts cached (almost everybody) will
  experience same problems as in 1, possibly getting two versions in
  the classpath

 I don't know whether I should laugh or cry because you offered option 2
 at all. I took option 2 and adjusted all the old releases of XStream on the
 Codehaus repo, but they do not get synced to the public repo, since the
 space for the relocation POMs is already occupied by the old files. It was
 you who said, nothing can be done about this. Why should the synchronization
 of the Apache repo be different to the one of Codehaus?

 - Jörg

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]






--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r507429 - in /jakarta/commons/proper/fileupload/trunk: build.xml pom.xml project.xml