Hi folks,
would it be possible to release Commons Fileupload 1.4.1? 1.4 still
contains commons-io 2.2 and requires to explicitly exclude it
(CVE-2021-29425).
Thanks,
Dennis
-
To unsubscribe, e-mail: dev-unsubscr...@commons.
valuable time as they best see fit ;-)
>
> Gary
>
> On Wed, Dec 7, 2022, 10:49 Dennis Kieselhorst wrote:
>
> > Hi folks,
> >
> > would it be possible to release Commons Fileupload 1.4.1? 1.4 still
> > contains commons-io 2.2 and requires to explicitly exc
+1
Thanks Gary, it will be a cleaner solution.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hi Gary,
successfully tested the latest SNAPSHOT with the new module structure
yesterday. Please release it.
Thanks,
Dennis
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@
Hi Gary,
what's blocking the 2.0.0-M1 release? Can I help implementing it?
Best,
Dennis
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
It's not redundant as Servlet API is just the API and commons-fileupload offers
a server-side implementation that even Tomcat could use (forked code lives here
https://github.com/apache/tomcat/tree/main/java/org/apache/tomcat/util/http/fileupload).
See also: https://issues.apache.org/jira/browse
Hmm why should every server create it's own impl instead of sharing
capabilities like multipart handling and parsing as a common library?
I agree with the consumer part but the lib is still useful in the future to
handle server side of things
Dennis
> Not sure I get the why, let me summarize:
>
> * using [fileupload] in a servlet >= 3 container is conflicting and can
> easily mess up things
> * servlet provides [fileupload] api
> * jetty (since you mentionned it) does not use [fileupload] (
> https://github.com/eclipse/jetty.project/blob/jett
+1
Thanks Gary!
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Changed the build from JDK 1.6 to JDK 1.7 to fix that.
See also https://issues.apache.org/jira/browse/INFRA-13556
Regards
Dennis
Am 08.03.2017 um 22:03 schrieb Apache Jenkins Server:
> Parsing POMs
> Established TCP socket on 44316
> maven33-agent.jar already up to date
> maven33-interceptor.jar
Hi,
can you trigger an update of the pattern on
https://nvd.nist.gov/vuln/detail/CVE-2016-131 somehow? Currently OWASP
dependency check still considers 1.3.3 as insecure.
Cheers
Dennis
-
To unsubscribe, e-mail: dev-unsubsc
You can't move it as https://issues.jenkins-ci.org/browse/JENKINS-6961
isn't resolved yet.
I noticed there is already another one
https://builds.apache.org/view/A-D/view/Commons/ so we can delete the
top level view.
Regards
Dennis
---
Hi!
http://commons.apache.org/proper/commons-configuration/integration.html
links to https://continuum-ci.apache.org which no longer exists. What
about setting up a job on http://builds.apache.org?
Regards
Dennis
-
To unsubscrib
>
>> http://commons.apache.org/proper/commons-configuration/integration.html
>> links to https://continuum-ci.apache.org which no longer exists. What
>> about setting up a job on http://builds.apache.org?
> no objections from my side.
>
>
Alright currently I've no permission to create jobs, so eit
Am 07.05.2016 um 16:44 schrieb Oliver Heger:
> Thank you for updating build.xml.
>
> There has been some discussion to drop the ant build completely as it
> tends to become outdated. Most Commons components already did this, and
> I would be in favor of this.
>
>
Definitely +1, I was wondering why
>>> http://commons.apache.org/proper/commons-configuration/integration.html
>>> links to https://continuum-ci.apache.org which no longer exists. What
>>> about setting up a job on http://builds.apache.org?
>> no objections from my side.
A build is now configured here:
https://builds.apache.org/jo
> Are you're talking about the Continuous Integration report of the web site
> [1]? That is generated from the ciManagement section of pom.xml [2]. You
> have to modify/add the section to configurations pom.xml and then redeploy
> the website using maven site-deploy [3].
Ok, I see it's defined in
> Hm, at least builds #4 and #5 have been started manually. I also do
> not understand, from where Jenkins drags this special email address.
> It is my company address which I - to my knowledge - never used for my
> OSS activities. This is what I find a bit spooky.
Build #3 failed with some strange
Am 07.06.2016 um 01:58 schrieb Gary Gregory:
> On Mon, Jun 6, 2016 at 4:48 PM, Ralph Goers
> wrote:
>
>> If that file is bad I would suspect every build running on that server
>> would be failing. The server is jenkins-test-c83. As you know we were
>> told not to use any of the jerkins-test serv
+1
Am 24.07.2016 um 22:31 schrieb Oliver Heger:
> Hi all,
>
> there have been a number of bug fixes and also some new features for
> [configuration] since version 2.0 has been released. Those should be
> made available to the public. This is the vote for the 2.1 release.
>
> Configuration 2.1 RC1
> Any proposals which version of the checkstyle plugin would be
> compatible? Or why does the checkstyle plugin becomes active for a mvn
> clean install at all?
>
Sorry, I simply changed it to latest version without noticing that Java
7 is now required.
According to
https://maven.apache.org/plugi
+1
Am 30.07.2016 um 22:02 schrieb Oliver Heger:
> Hi all,
>
> after the failed vote for RC1 a new RC has been created. The only
> difference is that the checkstyle plugin has been downgraded which
> should allow building the project on Java 1.6.
>
> Configuration 2.1 RC2 is available for review he
Hi Benedikt!
> The build log is here [1]. It looks like some generated classes are checked
> by checkstyle which causes the build to fail. The build works with Java 7
> and Java 8. So my vote again is -1 because I think mvn clean install should
> work with the minimum required JDK out of the box.
Am 01.08.2016 um 21:31 schrieb Oliver Heger:
> Am 31.07.2016 um 22:24 schrieb Matt Sicker:
>> Fixing all the checkstyle errors first is kind of a prerequisite to
>> enabling it by default.
>>
>> On 31 July 2016 at 15:10, Charles Honton wrote:
>>
>>> Why wouldn’t we want build to fail early if inco
Hi Gary!
> We have a mini-mess here:
>
> - checkstyle's check is called from the build and it fails.
> - Did it ever work?
> - Did it work and then the code degraded between the last release and this
> code base? The 2.0 checkstyle is clean:
> https://commons.apache.org/proper/commons-configuration
Am 06.08.2016 um 17:51 schrieb Emmanuel Bourg:
> Le 2/08/2016 à 21:17, Oliver Heger a écrit :
>
>> Well, for me style is not that important. (We cannot even agree on a
>> common style for the Commons project.) Therefore, seeing the violations
>> in the report is sufficient for me.
> +1, the build s
Hi Oliver!
> so do we have a confirmation that the current state in trunk builds
> correctly on the problematic platforms? Then I could start preparing
> another RC in the next days.
>
As the checkstyle config is now adapted, please prepare another RC.
Cheers
Dennis
--
Am 12.08.2016 um 01:18 schrieb Gary Gregory:
> -1
>
> From src zip: ASC, MD5, SHA1 OK.
>
> Building with:
>
> Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
> 05:51:28-0800)
> Maven home: E:\Java\apache-maven-3.0.5
> Java version: *1.6.0_45*, vendor: Sun Microsystems Inc.
Am 13.08.2016 um 21:37 schrieb Oliver Heger:
> a) Accept the RC as is and ignore this issue.
>
> b) Add a note to the building documentation that the site build requires
> a minimum JDK of 1.7. This is a change of the site and does not require
> another RC.
+1 for a or b.
Regards
Dennis
-
29 matches
Mail list logo
