Currently plexus-archiver uses platform encoding for zip file names if
none is specified. This is compliant with traditional Zip history.
But zip understood this is a problem and introduced a LEF flag,
which basically means all entries must be UTF-8.
I would like to switch defaults in plexus zip
Zip has a default timestamp granularity of 2 seconds. Adding the X5455
field increases this granularity to a level where we can pack/unpack a
jar/zip file and expect to retain the timestamp of the original .class
file.
Jar itself does not understand X5455 and will apply 2 second
rounding (but jar
As this is a step towards reproducable builds I see this as a good thing.
Depending on platform defaults should be punished...:-)
/Anders
On Fri, Oct 10, 2014 at 8:26 AM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
Currently plexus-archiver uses platform encoding for zip file
Hi,
+1 from too...
On 10/10/14 8:45 AM, Anders Hammar wrote:
As this is a step towards reproducable builds I see this as a good thing.
Depending on platform defaults should be punished...:-)
Yes... ;-)
/Anders
On Fri, Oct 10, 2014 at 8:26 AM, Kristian Rosenvold
Hi Kristina,
just a question on this topic...does currently jar from plexus-archiver
already behave like this and uses UTF-8 encoding always ? Or is this
platform dependent?
On 10/10/14 8:26 AM, Kristian Rosenvold wrote:
Currently plexus-archiver uses platform encoding for zip file names
No. It is platform encoding dependent. Which is why we have a bunch of
issues in maven-assembly-plugin about this behaviour.
The JAR archiver does this already, since its part of the jar spec.
Kristian
2014-10-10 11:58 GMT+02:00 Karl Heinz Marbaise khmarba...@gmx.de:
Hi Kristina,
just a
I am looking at all the encoding-related issues in assembly now btw.
Kristian
2014-10-10 12:16 GMT+02:00 Kristian Rosenvold kristian.rosenv...@gmail.com:
No. It is platform encoding dependent. Which is why we have a bunch of
issues in maven-assembly-plugin about this behaviour.
The JAR
Hi Kristian,
On 10/10/14 12:16 PM, Kristian Rosenvold wrote:
No. It is platform encoding dependent. Which is why we have a bunch of
issues in maven-assembly-plugin about this behaviour.
Ok...so i think this issue http://jira.codehaus.org/browse/MJAR-135 is
related to this behaviour as
On 2014-10-10, Kristian Rosenvold wrote:
This will break builds for people that actually *want* archives in
file.encoding; they will need to explicitly specify encoding to get
that encoding. To my understanding this is not really an issue, LEF
support is ancient history.
At the time where I
Hi folks,
how do we actually proceed with third-party plugins which do not comply to our
naming pattern [1]?
Given that a plugin has been created before this document has beeen first
published 2013-01-02.
Should they simply add a disclaimer for legacy reasons? What about plugins on
Central
They should rename going forward.
At some point (probably we could do so now) we will turn on enforcement in
the maven-plugin-plugin.
If they have not renamed then they will be stuck with the older tooling.
On 10 October 2014 12:08, Michael Osipov 1983-01...@gmx.net wrote:
Hi folks,
how do
They should rename going forward.
At some point (probably we could do so now) we will turn on enforcement in
the maven-plugin-plugin.
This will of course piss of a lot of people. Wouldn't it?
There are, of course, several reasons why people can't:
1. Popularity of the old name
2. Technical
1. We sent an announcement a long time ago.
2. We switched the maven-plugin-plugin to a warning a good while ago:
https://github.com/apache/maven-plugin-tools/commit/f88a58cecb4599e70b8fecf8b13d77d5e084be9c
If people have ignored that warning for three years, then we have done all
we can. The
Keep in mind that what we have here is almost certainly a
_convention_, not a point of trademark law. As I understand it, we'd
as likely be laughed at for the suggestion that reversing the order of
the components of a name leads to 'marketplace confusion' at the level
at which trademarks can be
We, the PMC, agreed to allow permitted usage of the form ___-maven-plugin
as that clarified that the plugin was a plugin for maven not one produced
by maven
On 10 October 2014 12:40, Benson Margulies bimargul...@gmail.com wrote:
Keep in mind that what we have here is almost certainly a
On Fri, Oct 10, 2014 at 7:42 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
We, the PMC, agreed to allow permitted usage of the form ___-maven-plugin
as that clarified that the plugin was a plugin for maven not one produced
by maven
Yea, I know, and I'm not opposed to making the
We just need to show best effort to defend our trademark... if we *see*
anyone doing that then we have to send them CD letters...
Note: my understanding is that we only have to send CD letters when we
know somebody is abusing our mark... we don't necessarily have to go
actively looking for people
Hi,
On 10/10/14 1:25 PM, Michael Osipov wrote:
They should rename going forward.
At some point (probably we could do so now) we will turn on enforcement in
the maven-plugin-plugin.
This will of course piss of a lot of people. Wouldn't it?
There are, of course, several reasons why people
If you do a quick search on Central, you'll that even other Apache project
don't adhere to this convention. Should they receive a CD too?
Michael
We just need to show best effort to defend our trademark... if we *see*
anyone doing that then we have to send them CD letters...
Note: my
GitHub user llebegue opened a pull request:
https://github.com/apache/maven-scm/pull/22
SCM-764 : Fix password displayed in cl.toString()
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/llebegue/maven-scm master
Alternatively
Yes
On 10 October 2014 13:12, Michael Osipov 1983-01...@gmx.net wrote:
If you do a quick search on Central, you'll that even other Apache project
don't adhere to this convention. Should they receive a CD too?
Michael
We just need to show best effort to defend our trademark... if we *see*
Thankfully for you, you are not on the PMC... if you were on the PMC and
you did such a search you would then have to go and send CDs.
/me runs away from this thread in case I happen to be made aware of any
trademark misuse ;-)
On 10 October 2014 13:39, Stephen Connolly
Yes, resposibility isn't always good.
Shouldn't simply make the build fail instead of log when such a collision
happens?
Michael
Thankfully for you, you are not on the PMC... if you were on the PMC and
you did such a search you would then have to go and send CDs.
/me runs away from this
That was the plan 3 years ago we decided to warn first and then switch
on failing after a while... now is a good time, perhaps you could commit
the change to fail the build?
On 10 October 2014 13:48, Michael Osipov 1983-01...@gmx.net wrote:
Yes, resposibility isn't always good.
Shouldn't
Fine, I'd like to note that first:
1. Shouldn't we announce this publically on the users mailing list?
2. I think that this deserves a major bump in plugin version. WDYT?
Michael
Gesendet: Freitag, 10. Oktober 2014 um 15:23 Uhr
Von: Stephen Connolly stephen.alan.conno...@gmail.com
An: Maven
I would prefer this should be part of Maven Core's warning system. If the
plugin starts with maven- and it's not an org.apache.maven.plugins group,
then we should spit out the error. I am not sure enforcer is the right
place for this rule; this is more of a global problem than a suggestion for
On Friday, 10 October 2014, Michael Osipov 1983-01...@gmx.net wrote:
Fine, I'd like to note that first:
1. Shouldn't we announce this publically on the users mailing list?
Yes as part of announcing the maven-plugin-plugin release
2. I think that this deserves a major bump in plugin
I suspect defaulting to UTF-8/LEF will work ok for most people, I
will do some tests on windows.
There's probably 1 billion chinese that rely on CP936 platform default
encoding on windows XP (IE6
all over again) but I suspect they will be better of making an
explicit specification of the
Hi,
On 10/10/14 3:41 PM, Paul Benedict wrote:
I would prefer this should be part of Maven Core's warning system. If the
plugin starts with maven- and it's not an org.apache.maven.plugins group,
then we should spit out the error. I am not sure enforcer is the right
place for this rule; this is
Hi,
someone else?
Kind regards
Karl Heinz Marbaise
On 10/9/14 12:57 PM, Karl Heinz Marbaise wrote:
Hi,
here is my +1 for this release.
On 10/7/14 9:45 PM, Karl Heinz Marbaise wrote:
Hi,
We solved 4 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11147version=20597
+1
2014-10-07 21:45 GMT+02:00 Karl Heinz Marbaise khmarba...@gmx.de:
Hi,
We solved 4 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11147version=20597
There are still a couple of issues left in JIRA:
Hi,
On 10/10/14 3:41 PM, Paul Benedict wrote:
I would prefer this should be part of Maven Core's warning system. If the
plugin starts with maven- and it's not an org.apache.maven.plugins group,
then we should spit out the error. I am not sure enforcer is the right
place for this rule;
Am 10/10/14 14:00, schrieb Karl Heinz Marbaise:
Hi,
On 10/10/14 1:25 PM, Michael Osipov wrote:
They should rename going forward.
At some point (probably we could do so now) we will turn on enforcement in
the maven-plugin-plugin.
This will of course piss of a lot of people. Wouldn't it?
Hi,
On 10/10/14 4:20 PM, Michael Osipov wrote:
Hi,
On 10/10/14 3:41 PM, Paul Benedict wrote:
I would prefer this should be part of Maven Core's warning system. If the
plugin starts with maven- and it's not an org.apache.maven.plugins group,
then we should spit out the error. I am not sure
Hi,
On 10/10/14 4:31 PM, Christian Schulte wrote:
Am 10/10/14 14:00, schrieb Karl Heinz Marbaise:
Hi,
On 10/10/14 1:25 PM, Michael Osipov wrote:
They should rename going forward.
At some point (probably we could do so now) we will turn on enforcement in
the maven-plugin-plugin.
This will
relocations only make sense with version ranges and even then they
don't make much sense.
On 10 October 2014 15:31, Christian Schulte c...@schulte.it wrote:
Am 10/10/14 14:00, schrieb Karl Heinz Marbaise:
Hi,
On 10/10/14 1:25 PM, Michael Osipov wrote:
They should rename going
I agree that maven core should issue warnings on the plugin names... but we
cannot break builds for people upgrading maven with a fully locked down pom
(otherwise we'll never persuade them to upgrade, so IMHO core should warn
only and never break... maven-plugin-plugin however should just break
Agreed, Stephen. A warning should be emitted. A build should not break.
Cheers,
Paul
On Fri, Oct 10, 2014 at 9:57 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
I agree that maven core should issue warnings on the plugin names... but we
cannot break builds for people upgrading
On 2014-10-10, Kristian Rosenvold wrote:
I will investigate some modern windows. I suppose this may cook down
to various unicode normalization forms on different OS'es. Does
commons compress deal with mac-os unicode normalization ? (e.g does it
handle Piñata on mac over to a PC ) ?
TBH I'm
Hi Robert,
On 10/9/14 7:24 PM, Robert Scholte wrote:
Op Wed, 08 Oct 2014 22:35:08 +0200 schreef Karl Heinz Marbaise
khmarba...@gmx.de:
Hi Robert,
+1 for the code/artifact
I'm a bit surprised by the site. The menu seems outdated: e.g. it
contains a reference to maven-1.x
Do you mean
Hi,
i need one more binding vote ?
Kind regards
Karl-Heinz Marbaise
On 10/7/14 9:45 PM, Karl Heinz Marbaise wrote:
Hi,
We solved 4 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11147version=20597
There are still a couple of issues left in JIRA:
GitHub user Tibor17 opened a pull request:
https://github.com/apache/maven-surefire/pull/56
[SUREFIRE-1080] Use parallel and fork together run some tests multiple times
Fix for SUREFIRE-1080.
http://jira.codehaus.org/browse/SUREFIRE-1080
You can merge this pull request into a
+1
On Friday, 10 October 2014, Karl Heinz Marbaise khmarba...@gmx.de wrote:
Hi,
i need one more binding vote ?
Kind regards
Karl-Heinz Marbaise
On 10/7/14 9:45 PM, Karl Heinz Marbaise wrote:
Hi,
We solved 4 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?
+1
Regards,
Hervé
Le mardi 7 octobre 2014 21:45:55 Karl Heinz Marbaise a écrit :
Hi,
We solved 4 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11147version=205
97
There are still a couple of issues left in JIRA:
+1
Regards,
Hervé
Le mercredi 8 octobre 2014 13:30:19 Karl Heinz Marbaise a écrit :
Hi,
We solved 7 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12100version=169
06
There is still one issues left in JIRA:
45 matches
Mail list logo
