+1
Thanks Gary!
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
> 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
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
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
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
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...@
+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
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
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.
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,
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
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
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
-
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.
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 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 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 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 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.
+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
> 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 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
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
> 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
> 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
>>> 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
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.
>
>
Alright currently I've no permission to create jobs, so eit
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
29 matches
Mail list logo
