[jira] [Commented] (MNG-5883) Silence unnecessary legacy local repository warning
[
https://issues.apache.org/jira/browse/MNG-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16420983#comment-16420983
]
Ben Caradoc-Davies commented on MNG-5883:
-
I agree with Cristian: the new mode should be removed. The core problem is that
the new mode stores too much state in the local repository. In effect,
artifacts now have not only groupId, artifactId, and version, but also a
persistent origin that is set once and cannot be accessed from poms. The new
mode is broken because it neglects the possibility that the origin might
change, but this happens all the time in the real world. The new mode confuses
the means of access (repository) with the payload (artifact). This analogous to
mixing the transport and application layers in a network model.
The new behaviour increases stability but this is orthogonal to correctness. A
build can be stable and broken. Under the new behaviour, once the local
repository has been poisoned with a bad artifact (e.g. corrupt zero-length jar
or artifact built and deployed with wrong Java target), it will be stably
broken, and cannot be fixed by adding a good artifact to a different
repository. Manual repair of a local repository can be difficult if it is on a
remote CI machine (who has admin on that box?). Not to mention all the confused
developers who are unaware of Maven's broken default (new) behaviour, do not
know that their local repository is poisoned, cannot figure out why their build
is failing, and wander project developer mailing lists and stackexchange
seeking help.
If you want to bind artifacts to particular repositories (and I do not think
this is as useful as you think), please implement this behaviour in the pom
model, not as hidden state in the local repository.
Until the new mode is removed, I use and recommend "-llr".
> Silence unnecessary legacy local repository warning
> ---
>
> Key: MNG-5883
> URL: https://issues.apache.org/jira/browse/MNG-5883
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3, 3.5.0
>Reporter: Ben Caradoc-Davies
>Priority: Trivial
>
> Having been burned on several occasions by the new local repository
> behaviour, which in effect scopes artifacts by their origin (when first
> stored in the local repository), I was delighted by the introduction of the
> -llr command line option in 3.0.3. I now use this behaviour for all builds to
> avoid the build instability caused by remote repository migration. This
> avoids the need to start each build with:
> {code}
> find ~/.m2/repository -name "_*.repositories" -exec rm -f {} \;
> {code}
> Given that users of -llr have made an informed choice to do so, please remove
> the (in my view unnecessary) warning that it generates:
> {code}
> [WARNING] Disabling enhanced local repository: using legacy is strongly
> discouraged to ensure build reproducibility.
> {code}
> Kind regards,
> Ben.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6323) Deadlock in multithreaded dependency resolution
[
https://issues.apache.org/jira/browse/MNG-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16298993#comment-16298993
]
Ben Caradoc-Davies commented on MNG-6323:
-
Another Travis user reports that they were also affected by this bug and able
to work around it by downgrading to Maven 3.5.0:
https://github.com/travis-ci/travis-ci/issues/8932
> Deadlock in multithreaded dependency resolution
> ---
>
> Key: MNG-6323
> URL: https://issues.apache.org/jira/browse/MNG-6323
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Ben Caradoc-Davies
> Attachments: geoserver-community-maven-hang-jstack-2.txt,
> geoserver-community-maven-hang-jstack.txt
>
>
> Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven
> 3.5.0.
> To reproduce the issue, clone GeoServer:
> {noformat}
> git clone https://github.com/geoserver/geoserver.git
> cd geoserver
> {noformat}
> Build GeoServer community modules with:
> {noformat}
> mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease
> -DskipTests clean install
> {noformat}
> Builds that normally take 2-4 minutes instead experience long hangs.
> {{jstack}} output (attached) suggests a deadlock (two different hangs
> attached). Some of the locks are in {{TIME_WAIT}} and eventually the build
> completes after 30-45 minutes, but this is enough to cause builds on Travis
> to be killed for their failure to output for ten minutes. (Travis upgraded to
> Maven 3.5.2 a week ago.)
> I have only seen the failures with -U. The hang does not occur in
> single-threaded builds. There are no "*.lock" files in the local repository
> during the hang so the deadlocks are not mediated by the filesystem. CPU
> utilisation is zero suggesting a deadlock not a livelock.
> See also discussion on the geoserver-devel mailing list:
> http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6323) Deadlock in multithreaded dependency resolution
[
https://issues.apache.org/jira/browse/MNG-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Caradoc-Davies updated MNG-6323:
Description:
Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven
3.5.0.
To reproduce the issue, clone GeoServer:
{noformat}
git clone https://github.com/geoserver/geoserver.git
cd geoserver
{noformat}
Build GeoServer community modules with:
{noformat}
mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease -DskipTests
clean install
{noformat}
Builds that normally take 2-4 minutes instead experience long hangs. {{jstack}}
output (attached) suggests a deadlock (two different hangs attached). Some of
the locks are in {{TIME_WAIT}} and eventually the build completes after 30-45
minutes, but this is enough to cause builds on Travis to be killed for their
failure to output for ten minutes. (Travis upgraded to Maven 3.5.2 a week ago.)
I have only seen the failures with -U. The hang does not occur in
single-threaded builds. There are no "*.lock" files in the local repository
during the hang so the deadlocks are not mediated by the filesystem. CPU
utilisation is zero suggesting a deadlock not a livelock.
See also discussion on the geoserver-devel mailing list:
http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html
was:
Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven
3.5.0.
To reproduce the issue, clone GeoServer:
{noformat}
git clone https://github.com/geoserver/geoserver.git
cd geoserver
{noformat}
Build GeoServer community modules with:
{noformat}
mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease -DskipTests
clean install
{noformat}
Builds that normally take 2-4 minutes instead experience long hangs. {{jstack}}
output (attached) suggests a deadlock (two different hangs attached). Some of
the locks are in {{TIME_WAIT}} and eventually the build completes after 30-45
minutes, but this is enough to cause builds on Travis to be killed for their
failure to output for ten minutes. (Travis upgraded to Maven 3.5.2 a week ago.)
I have only seen the failures with -U. The hang does not occur in
single-threaded builds. There are no "*.lock" files in the local repository
during the hang so the locks are not mediated by the filesystem. CPU
utilisation is zero suggesting a deadlock not a livelock.
See also discussion on the geoserver-devel mailing list:
http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html
> Deadlock in multithreaded dependency resolution
> ---
>
> Key: MNG-6323
> URL: https://issues.apache.org/jira/browse/MNG-6323
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Ben Caradoc-Davies
> Attachments: geoserver-community-maven-hang-jstack-2.txt,
> geoserver-community-maven-hang-jstack.txt
>
>
> Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven
> 3.5.0.
> To reproduce the issue, clone GeoServer:
> {noformat}
> git clone https://github.com/geoserver/geoserver.git
> cd geoserver
> {noformat}
> Build GeoServer community modules with:
> {noformat}
> mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease
> -DskipTests clean install
> {noformat}
> Builds that normally take 2-4 minutes instead experience long hangs.
> {{jstack}} output (attached) suggests a deadlock (two different hangs
> attached). Some of the locks are in {{TIME_WAIT}} and eventually the build
> completes after 30-45 minutes, but this is enough to cause builds on Travis
> to be killed for their failure to output for ten minutes. (Travis upgraded to
> Maven 3.5.2 a week ago.)
> I have only seen the failures with -U. The hang does not occur in
> single-threaded builds. There are no "*.lock" files in the local repository
> during the hang so the deadlocks are not mediated by the filesystem. CPU
> utilisation is zero suggesting a deadlock not a livelock.
> See also discussion on the geoserver-devel mailing list:
> http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6323) Deadlock in multithreaded dependency resolution
[
https://issues.apache.org/jira/browse/MNG-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16295523#comment-16295523
]
Ben Caradoc-Davies commented on MNG-6323:
-
By the way, reverting MNG-6025 (be223808939d75152d7157db33d45f230114555e) did
not fix. I did not try reverting the upgrade to Resolver 1.1.0 (MNG-6258).
> Deadlock in multithreaded dependency resolution
> ---
>
> Key: MNG-6323
> URL: https://issues.apache.org/jira/browse/MNG-6323
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Ben Caradoc-Davies
> Attachments: geoserver-community-maven-hang-jstack-2.txt,
> geoserver-community-maven-hang-jstack.txt
>
>
> Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven
> 3.5.0.
> To reproduce the issue, clone GeoServer:
> {noformat}
> git clone https://github.com/geoserver/geoserver.git
> cd geoserver
> {noformat}
> Build GeoServer community modules with:
> {noformat}
> mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease
> -DskipTests clean install
> {noformat}
> Builds that normally take 2-4 minutes instead experience long hangs.
> {{jstack}} output (attached) suggests a deadlock (two different hangs
> attached). Some of the locks are in {{TIME_WAIT}} and eventually the build
> completes after 30-45 minutes, but this is enough to cause builds on Travis
> to be killed for their failure to output for ten minutes. (Travis upgraded to
> Maven 3.5.2 a week ago.)
> I have only seen the failures with -U. The hang does not occur in
> single-threaded builds. There are no "*.lock" files in the local repository
> during the hang so the locks are not mediated by the filesystem. CPU
> utilisation is zero suggesting a deadlock not a livelock.
> See also discussion on the geoserver-devel mailing list:
> http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6323) Deadlock in multithreaded dependency resolution
[
https://issues.apache.org/jira/browse/MNG-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Caradoc-Davies updated MNG-6323:
Description:
Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven
3.5.0.
To reproduce the issue, clone GeoServer:
{noformat}
git clone https://github.com/geoserver/geoserver.git
cd geoserver
{noformat}
Build GeoServer community modules with:
{noformat}
mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease -DskipTests
clean install
{noformat}
Builds that normally take 2-4 minutes instead experience long hangs. {{jstack}}
output (attached) suggests a deadlock (two different hangs attached). Some of
the locks are in {{TIME_WAIT}} and eventually the build completes after 30-45
minutes, but this is enough to cause builds on Travis to be killed for their
failure to output for ten minutes. (Travis upgraded to Maven 3.5.2 a week ago.)
I have only seen the failures with -U. The hang does not occur in
single-threaded builds. There are no "*.lock" files in the local repository
during the hang so the locks are not mediated by the filesystem. CPU
utilisation is zero suggesting a deadlock not a livelock.
See also discussion on the geoserver-devel mailing list:
http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html
was:
Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven
3.5.0.
To reproduce the issue, clone GeoServer:
{noformat}
git clone https://github.com/geoserver/geoserver.git
cd geoserver
{noformat}
Build GeoServer community modules with:
{noformat}
mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease -DskipTests
clean install
{noformat}
Builds that normally take 2-4 minutes instead experience long hangs. {{jstack}}
output (attached) suggests a deadlock (two different hangs attached). Some of
the locks are in {{TIME_WAIT}} and eventually the build completes after 30-45
minutes, but this is enough to cause builds on Travis to be killed for their
failure to output for ten minutes. (Travis upgraded to Maven 3.5.2 a week ago.)
I have only seen the failures with -U. The hang does not occur in
single-threaded builds.
See also discussion on the geoserver-devel mailing list:
http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html
> Deadlock in multithreaded dependency resolution
> ---
>
> Key: MNG-6323
> URL: https://issues.apache.org/jira/browse/MNG-6323
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Ben Caradoc-Davies
> Attachments: geoserver-community-maven-hang-jstack-2.txt,
> geoserver-community-maven-hang-jstack.txt
>
>
> Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven
> 3.5.0.
> To reproduce the issue, clone GeoServer:
> {noformat}
> git clone https://github.com/geoserver/geoserver.git
> cd geoserver
> {noformat}
> Build GeoServer community modules with:
> {noformat}
> mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease
> -DskipTests clean install
> {noformat}
> Builds that normally take 2-4 minutes instead experience long hangs.
> {{jstack}} output (attached) suggests a deadlock (two different hangs
> attached). Some of the locks are in {{TIME_WAIT}} and eventually the build
> completes after 30-45 minutes, but this is enough to cause builds on Travis
> to be killed for their failure to output for ten minutes. (Travis upgraded to
> Maven 3.5.2 a week ago.)
> I have only seen the failures with -U. The hang does not occur in
> single-threaded builds. There are no "*.lock" files in the local repository
> during the hang so the locks are not mediated by the filesystem. CPU
> utilisation is zero suggesting a deadlock not a livelock.
> See also discussion on the geoserver-devel mailing list:
> http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MNG-6323) Deadlock in multithreaded dependency resolution
[
https://issues.apache.org/jira/browse/MNG-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Caradoc-Davies updated MNG-6323:
Description:
Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven
3.5.0.
To reproduce the issue, clone GeoServer:
{noformat}
git clone https://github.com/geoserver/geoserver.git
cd geoserver
{noformat}
Build GeoServer community modules with:
{noformat}
mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease -DskipTests
clean install
{noformat}
Builds that normally take 2-4 minutes instead experience long hangs. {{jstack}}
output (attached) suggests a deadlock (two different hangs attached). Some of
the locks are in {{TIME_WAIT}} and eventually the build completes after 30-45
minutes, but this is enough to cause builds on Travis to be killed for their
failure to output for ten minutes. (Travis upgraded to Maven 3.5.2 a week ago.)
I have only seen the failures with -U. The hang does not occur in
single-threaded builds.
See also discussion on the geoserver-devel mailing list:
http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html
was:
Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven
3.5.0.
To reproduce the issue, clone GeoServer:
{noformat}
git clone https://github.com/geoserver/geoserver.git
cd geoserver
{noformat}
Build GeoServer community modules with:
{noformat}
mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease -DskipTests
clean install
{noformat}
Builds that normally take 2-4 minutes instead experience long hangs. {{jstack}}
output (attached) suggests a deadlock (two different hangs attached). Some of
the locks are in {{TIME_WAIT}} and eventually the build completes after 30-45
minutes, but this is enough to cause builds on Travis to be killed for their
failure to output for ten minutes. (Travis upgraded to Maven 3.5.2 a week ago.)
I have only seen the failures with -U. The hang does not occur in
single-threaded builds.
See also discussion on the geoserver-devel mailing list:
http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html
See also discussion
> Deadlock in multithreaded dependency resolution
> ---
>
> Key: MNG-6323
> URL: https://issues.apache.org/jira/browse/MNG-6323
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Ben Caradoc-Davies
> Attachments: geoserver-community-maven-hang-jstack-2.txt,
> geoserver-community-maven-hang-jstack.txt
>
>
> Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven
> 3.5.0.
> To reproduce the issue, clone GeoServer:
> {noformat}
> git clone https://github.com/geoserver/geoserver.git
> cd geoserver
> {noformat}
> Build GeoServer community modules with:
> {noformat}
> mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease
> -DskipTests clean install
> {noformat}
> Builds that normally take 2-4 minutes instead experience long hangs.
> {{jstack}} output (attached) suggests a deadlock (two different hangs
> attached). Some of the locks are in {{TIME_WAIT}} and eventually the build
> completes after 30-45 minutes, but this is enough to cause builds on Travis
> to be killed for their failure to output for ten minutes. (Travis upgraded to
> Maven 3.5.2 a week ago.)
> I have only seen the failures with -U. The hang does not occur in
> single-threaded builds.
> See also discussion on the geoserver-devel mailing list:
> http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MNG-6323) Deadlock in multithreaded dependency resolution
Ben Caradoc-Davies created MNG-6323:
---
Summary: Deadlock in multithreaded dependency resolution
Key: MNG-6323
URL: https://issues.apache.org/jira/browse/MNG-6323
Project: Maven
Issue Type: Bug
Affects Versions: 3.5.2
Reporter: Ben Caradoc-Davies
Attachments: geoserver-community-maven-hang-jstack-2.txt,
geoserver-community-maven-hang-jstack.txt
Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven
3.5.0.
To reproduce the issue, clone GeoServer:
{noformat}
git clone https://github.com/geoserver/geoserver.git
cd geoserver
{noformat}
Build GeoServer community modules with:
{noformat}
mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease -DskipTests
clean install
{noformat}
Builds that normally take 2-4 minutes instead experience long hangs. {{jstack}}
output (attached) suggests a deadlock (two different hangs attached). Some of
the locks are in {{TIME_WAIT}} and eventually the build completes after 30-45
minutes, but this is enough to cause builds on Travis to be killed for their
failure to output for ten minutes. (Travis upgraded to Maven 3.5.2 a week ago.)
I have only seen the failures with -U. The hang does not occur in
single-threaded builds.
See also discussion on the geoserver-devel mailing list:
http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html
See also discussion
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-5883) Silence unnecessary legacy local repository warning
[
https://issues.apache.org/jira/browse/MNG-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980534#comment-15980534
]
Ben Caradoc-Davies commented on MNG-5883:
-
MNG-5185 and MNG-5181 are in the Issue Links section above. The core problem is
that the new repository behaviour is stateful: it remembers the repository of
origin of an artifact. I know this is by design; the consequences of this
decision are noted in this issue and in the two linked issues. It is not the
end of the world, but any solution that requires direct modification of a Maven
repository using {{find}} and {{rm}} is an indication that something is wrong
with the Maven implementation.
> Silence unnecessary legacy local repository warning
> ---
>
> Key: MNG-5883
> URL: https://issues.apache.org/jira/browse/MNG-5883
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3, 3.5.0
>Reporter: Ben Caradoc-Davies
>Assignee: Christian Schulte
>Priority: Trivial
>
> Having been burned on several occasions by the new local repository
> behaviour, which in effect scopes artifacts by their origin (when first
> stored in the local repository), I was delighted by the introduction of the
> -llr command line option in 3.0.3. I now use this behaviour for all builds to
> avoid the build instability caused by remote repository migration. This
> avoids the need to start each build with:
> {code}
> find ~/.m2/repository -name "_*.repositories" -exec rm -f {} \;
> {code}
> Given that users of -llr have made an informed choice to do so, please remove
> the (in my view unnecessary) warning that it generates:
> {code}
> [WARNING] Disabling enhanced local repository: using legacy is strongly
> discouraged to ensure build reproducibility.
> {code}
> Kind regards,
> Ben.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MNG-5883) Silence unnecessary legacy local repository warning
[
https://issues.apache.org/jira/browse/MNG-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15980277#comment-15980277
]
Ben Caradoc-Davies edited comment on MNG-5883 at 4/23/17 5:49 AM:
--
On 3.5.0 I see this:
{noformat}
[INFO] Disabling enhanced local repository: using legacy is strongly
discouraged to ensure build reproducibility.
{noformat}
This is still a warning, even though the log level has been reduced. What I
really wanted was the removal of this unnecessary complaint. Downgrading to
{{INFO}} does not achieve this. Can we downgrade further to {{DEBUG}}? Or get
rid of it entirely?
The new repository behaviour causes local snapshot builds to be ignored and
breaks remote repository migrations.
was (Author: bencaradocdavies):
On 3.5.0 I see this:
{noformat}
[INFO] Disabling enhanced local repository: using legacy is strongly
discouraged to ensure build reproducibility.
{noformat}
This is still a warning, even though the log level has been reduced. What I
really wanted was the removal of this unnecessary complaint. Downgrading to
{{INFO}} does not achieve this. Can we downgrade further to {{DEBUG}}?
> Silence unnecessary legacy local repository warning
> ---
>
> Key: MNG-5883
> URL: https://issues.apache.org/jira/browse/MNG-5883
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3, 3.5.0
>Reporter: Ben Caradoc-Davies
>Assignee: Christian Schulte
>Priority: Trivial
>
> Having been burned on several occasions by the new local repository
> behaviour, which in effect scopes artifacts by their origin (when first
> stored in the local repository), I was delighted by the introduction of the
> -llr command line option in 3.0.3. I now use this behaviour for all builds to
> avoid the build instability caused by remote repository migration. This
> avoids the need to start each build with:
> {code}
> find ~/.m2/repository -name "_*.repositories" -exec rm -f {} \;
> {code}
> Given that users of -llr have made an informed choice to do so, please remove
> the (in my view unnecessary) warning that it generates:
> {code}
> [WARNING] Disabling enhanced local repository: using legacy is strongly
> discouraged to ensure build reproducibility.
> {code}
> Kind regards,
> Ben.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-5883) Silence unnecessary legacy local repository warning
[
https://issues.apache.org/jira/browse/MNG-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Caradoc-Davies updated MNG-5883:
Fix Version/s: (was: 3.5.0-alpha-1)
(was: 3.5.0)
> Silence unnecessary legacy local repository warning
> ---
>
> Key: MNG-5883
> URL: https://issues.apache.org/jira/browse/MNG-5883
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3, 3.5.0
>Reporter: Ben Caradoc-Davies
>Assignee: Christian Schulte
>Priority: Trivial
>
> Having been burned on several occasions by the new local repository
> behaviour, which in effect scopes artifacts by their origin (when first
> stored in the local repository), I was delighted by the introduction of the
> -llr command line option in 3.0.3. I now use this behaviour for all builds to
> avoid the build instability caused by remote repository migration. This
> avoids the need to start each build with:
> {code}
> find ~/.m2/repository -name "_*.repositories" -exec rm -f {} \;
> {code}
> Given that users of -llr have made an informed choice to do so, please remove
> the (in my view unnecessary) warning that it generates:
> {code}
> [WARNING] Disabling enhanced local repository: using legacy is strongly
> discouraged to ensure build reproducibility.
> {code}
> Kind regards,
> Ben.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MNG-5883) Silence unnecessary legacy local repository warning
[
https://issues.apache.org/jira/browse/MNG-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Caradoc-Davies updated MNG-5883:
Affects Version/s: 3.5.0
> Silence unnecessary legacy local repository warning
> ---
>
> Key: MNG-5883
> URL: https://issues.apache.org/jira/browse/MNG-5883
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3, 3.5.0
>Reporter: Ben Caradoc-Davies
>Assignee: Christian Schulte
>Priority: Trivial
>
> Having been burned on several occasions by the new local repository
> behaviour, which in effect scopes artifacts by their origin (when first
> stored in the local repository), I was delighted by the introduction of the
> -llr command line option in 3.0.3. I now use this behaviour for all builds to
> avoid the build instability caused by remote repository migration. This
> avoids the need to start each build with:
> {code}
> find ~/.m2/repository -name "_*.repositories" -exec rm -f {} \;
> {code}
> Given that users of -llr have made an informed choice to do so, please remove
> the (in my view unnecessary) warning that it generates:
> {code}
> [WARNING] Disabling enhanced local repository: using legacy is strongly
> discouraged to ensure build reproducibility.
> {code}
> Kind regards,
> Ben.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (MNG-5883) Silence unnecessary legacy local repository warning
[
https://issues.apache.org/jira/browse/MNG-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Caradoc-Davies reopened MNG-5883:
-
On 3.5.0 I see this:
{noformat}
[INFO] Disabling enhanced local repository: using legacy is strongly
discouraged to ensure build reproducibility.
{noformat}
This is still a warning, even though the log level has been reduced. What I
really wanted was the removal of this unnecessary complaint. Downgrading to
{{INFO}} does not achieve this. Can we downgrade further to {{DEBUG}}?
> Silence unnecessary legacy local repository warning
> ---
>
> Key: MNG-5883
> URL: https://issues.apache.org/jira/browse/MNG-5883
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3, 3.5.0
>Reporter: Ben Caradoc-Davies
>Assignee: Christian Schulte
>Priority: Trivial
>
> Having been burned on several occasions by the new local repository
> behaviour, which in effect scopes artifacts by their origin (when first
> stored in the local repository), I was delighted by the introduction of the
> -llr command line option in 3.0.3. I now use this behaviour for all builds to
> avoid the build instability caused by remote repository migration. This
> avoids the need to start each build with:
> {code}
> find ~/.m2/repository -name "_*.repositories" -exec rm -f {} \;
> {code}
> Given that users of -llr have made an informed choice to do so, please remove
> the (in my view unnecessary) warning that it generates:
> {code}
> [WARNING] Disabling enhanced local repository: using legacy is strongly
> discouraged to ensure build reproducibility.
> {code}
> Kind regards,
> Ben.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-5883) Silence unnecessary legacy local repository warning
[
https://issues.apache.org/jira/browse/MNG-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15114733#comment-15114733
]
Ben Caradoc-Davies commented on MNG-5883:
-
Thanks very much. I will be sure to test when 3.4.0 is released.
> Silence unnecessary legacy local repository warning
> ---
>
> Key: MNG-5883
> URL: https://issues.apache.org/jira/browse/MNG-5883
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
>Reporter: Ben Caradoc-Davies
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
>
> Having been burned on several occasions by the new local repository
> behaviour, which in effect scopes artifacts by their origin (when first
> stored in the local repository), I was delighted by the introduction of the
> -llr command line option in 3.0.3. I now use this behaviour for all builds to
> avoid the build instability caused by remote repository migration. This
> avoids the need to start each build with:
> {code}
> find ~/.m2/repository -name "_*.repositories" -exec rm -f {} \;
> {code}
> Given that users of -llr have made an informed choice to do so, please remove
> the (in my view unnecessary) warning that it generates:
> {code}
> [WARNING] Disabling enhanced local repository: using legacy is strongly
> discouraged to ensure build reproducibility.
> {code}
> Kind regards,
> Ben.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-5883) Silence unnecessary legacy local repository warning
Ben Caradoc-Davies created MNG-5883:
---
Summary: Silence unnecessary legacy local repository warning
Key: MNG-5883
URL: https://issues.apache.org/jira/browse/MNG-5883
Project: Maven
Issue Type: Improvement
Components: Command Line
Affects Versions: 3.3.3, 3.2.5
Reporter: Ben Caradoc-Davies
Priority: Trivial
Having been burned on several occasions by the new local repository behaviour,
which in effect scopes artifacts by their origin (when first stored in the
local repository), I was delighted by the introduction of the -llr command line
option in 3.0.3. I now use this behaviour for all builds to avoid the build
instability caused by remote repository migration. This avoids the need to
start each build with:
{code}
find ~/.m2/repository -name _*.repositories -exec rm -f {} \;
{code}
Given that users of -llr have made an informed choice to do so, please remove
the (in my view unnecessary) warning that it generates:
{code}
[WARNING] Disabling enhanced local repository: using legacy is strongly
discouraged to ensure build reproducibility.
{code}
Kind regards,
Ben.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5883) Silence unnecessary legacy local repository warning
[
https://issues.apache.org/jira/browse/MNG-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Caradoc-Davies updated MNG-5883:
Description:
Having been burned on several occasions by the new local repository behaviour,
which in effect scopes artifacts by their origin (when first stored in the
local repository), I was delighted by the introduction of the -llr command line
option in 3.0.3. I now use this behaviour for all builds to avoid the build
instability caused by remote repository migration. This avoids the need to
start each build with:
{code}
find ~/.m2/repository -name "_*.repositories" -exec rm -f {} \;
{code}
Given that users of -llr have made an informed choice to do so, please remove
the (in my view unnecessary) warning that it generates:
{code}
[WARNING] Disabling enhanced local repository: using legacy is strongly
discouraged to ensure build reproducibility.
{code}
Kind regards,
Ben.
was:
Having been burned on several occasions by the new local repository behaviour,
which in effect scopes artifacts by their origin (when first stored in the
local repository), I was delighted by the introduction of the -llr command line
option in 3.0.3. I now use this behaviour for all builds to avoid the build
instability caused by remote repository migration. This avoids the need to
start each build with:
{code}
find ~/.m2/repository -name _*.repositories -exec rm -f {} \;
{code}
Given that users of -llr have made an informed choice to do so, please remove
the (in my view unnecessary) warning that it generates:
{code}
[WARNING] Disabling enhanced local repository: using legacy is strongly
discouraged to ensure build reproducibility.
{code}
Kind regards,
Ben.
> Silence unnecessary legacy local repository warning
> ---
>
> Key: MNG-5883
> URL: https://issues.apache.org/jira/browse/MNG-5883
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5, 3.3.3
>Reporter: Ben Caradoc-Davies
>Priority: Trivial
>
> Having been burned on several occasions by the new local repository
> behaviour, which in effect scopes artifacts by their origin (when first
> stored in the local repository), I was delighted by the introduction of the
> -llr command line option in 3.0.3. I now use this behaviour for all builds to
> avoid the build instability caused by remote repository migration. This
> avoids the need to start each build with:
> {code}
> find ~/.m2/repository -name "_*.repositories" -exec rm -f {} \;
> {code}
> Given that users of -llr have made an informed choice to do so, please remove
> the (in my view unnecessary) warning that it generates:
> {code}
> [WARNING] Disabling enhanced local repository: using legacy is strongly
> discouraged to ensure build reproducibility.
> {code}
> Kind regards,
> Ben.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5882) Nonportable shell constructs cause bin/mvn errors on Debian
[
https://issues.apache.org/jira/browse/MNG-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Caradoc-Davies updated MNG-5882:
Attachment: mvn-dash.patch
> Nonportable shell constructs cause bin/mvn errors on Debian
> ---
>
> Key: MNG-5882
> URL: https://issues.apache.org/jira/browse/MNG-5882
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.3
> Environment: debian/unstable with dash 0.5.7-4+b1 amd64
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
> 2015-04-22T23:57:37+12:00)
> Maven home: /home/ben/java/maven
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.1.0-2-amd64", arch: "amd64", family: "unix"
>Reporter: Ben Caradoc-Davies
> Attachments: mvn-dash.patch
>
>
> bin/mvn includes both local and export commands that perform assignment but
> do not protect against word splitting. These cause failures on Debian when
> run in a path with spaces because /bin/sh is dash which performs word
> splitting for assignment in local and export commands. See discussion here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598239
> "Bash and others treat 'local' (just like export, etc) differently, but it's
> a
> known shell portability issue."
> For example, in this working directory:
> {noformat}
> /home/ben/geoserver/src with spaces/geotools
> {noformat}
> Running bin/mvn results in:
> {noformat}
> $ mvn [options]
> /home/ben/java/maven/bin/mvn: 200: local: spaces/geotools: bad variable name
> [...]
> {noformat}
> Moving the two local commands in find_maven_basedir to their own lines leaves:
> {noformat}
> $ mvn [options]
> /home/ben/java/maven/bin/mvn: 221: export: spaces/geotools: bad variable name
> {noformat}
> So the export command for MAVEN_PROJECTBASEDIR is also affected, and needs to
> be moved to the following line. This is a regression because bin/mvn from
> Maven 3.2.5 worked just fine on Debian in this working directory. Both
> problems are fixed in the attached patch.
> Another workaround is to change the bin/mvn interpreter from /bin/sh to
> /bin/bash.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5882) Nonportable shell constructs cause bin/mvn errors on Debian
[
https://issues.apache.org/jira/browse/MNG-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Caradoc-Davies updated MNG-5882:
Description:
bin/mvn includes both local and export commands that perform assignment but do
not protect against word splitting. These cause failures on Debian when run in
a path with spaces because /bin/sh is dash which performs word splitting for
assignment in local and export commands. See discussion here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598239
"Bash and others treat 'local' (just like export, etc) differently, but it's a
known shell portability issue."
For example, in this working directory:
{noformat}
/home/ben/geoserver/src with spaces/geotools
{noformat}
Running bin/mvn results in:
{noformat}
$ mvn [options]
/home/ben/java/maven/bin/mvn: 200: local: spaces/geotools: bad variable name
[...]
{noformat}
Moving the two local commands in find_maven_basedir to their own lines leaves:
{noformat}
$ mvn [options]
/home/ben/java/maven/bin/mvn: 221: export: spaces/geotools: bad variable name
{noformat}
So the export command for MAVEN_PROJECTBASEDIR is also affected, and needs to
be moved to the following line. This is a regression because bin/mvn from Maven
3.2.5 worked just fine on Debian in this working directory. Both problems are
fixed in the attached patch.
Another workaround is to change the bin/mvn interpreter from /bin/sh to
/bin/bash.
was:
bin/mvn includes both local and export commands that perform assignment but do
not protect against word splitting. These cause failures on Debian when run in
a path with spaces because /bin/sh is dash which performs word splitting for
assignment in local and export commands. See discussion here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598239
"Bash and others treat 'local' (just like export, etc) differently, but it's a
known shell portability issue."
For example, in this working directory:
{noformat}
/home/ben/geoserver/src with spaces/geotools
{noformat}
Running bin/mvn results in:
{noformat}
$ mvn [options]
/home/ben/java/maven/bin/mvn: 200: local: spaces/geotools: bad variable name
[...]
{noformat}
Moving the two local commands in find_maven_basedir to their own lines leaves:
{noformat}
$ mvn [options]
/home/ben/java/maven/bin/mvn: 221: export: spaces/geotools: bad variable name
{noformat}
So the export command for MAVEN_PROJECTBASEDIR is also affected, and needs to
be moved to the following line. This is a regression because bin/mvn from Maven
3.2.5 worked just fine on Debian in this working directory. Both problems are
fixed in the attached patch.
Another workaround is to change the bin/mvn interpreter from /bin/sh to
/bin/bash.
> Nonportable shell constructs cause bin/mvn errors on Debian
> ---
>
> Key: MNG-5882
> URL: https://issues.apache.org/jira/browse/MNG-5882
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.3
> Environment: debian/unstable with dash 0.5.7-4+b1 amd64
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
> 2015-04-22T23:57:37+12:00)
> Maven home: /home/ben/java/maven
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.1.0-2-amd64", arch: "amd64", family: "unix"
>Reporter: Ben Caradoc-Davies
> Attachments: mvn-dash.patch
>
>
> bin/mvn includes both local and export commands that perform assignment but
> do not protect against word splitting. These cause failures on Debian when
> run in a path with spaces because /bin/sh is dash which performs word
> splitting for assignment in local and export commands. See discussion here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598239
> "Bash and others treat 'local' (just like export, etc) differently, but it's
> a known shell portability issue."
> For example, in this working directory:
> {noformat}
> /home/ben/geoserver/src with spaces/geotools
> {noformat}
> Running bin/mvn results in:
> {noformat}
> $ mvn [options]
> /home/ben/java/maven/bin/mvn: 200: local: spaces/geotools: bad variable name
> [...]
> {noformat}
> Moving the two local commands in find_maven_basedir to their own lines leaves:
> {noformat}
> $ mvn [options]
> /home/ben/java/maven/bin/mvn: 221: export: spaces/geotools: bad variable name
> {noformat}
> So the export command for MAVEN_PROJECTBASEDIR is also affected, and needs to
> be moved to the following line. This is a regression because bin/mvn from
> Maven 3.2.5 worked just fine on Debian in this working directory. Both
> problems are fixed in the attached patch.
> Another workaround is to change the bin/mvn interpreter from /bin/sh to
> /bin/bash.
--
This message was
[jira] [Created] (MNG-5882) Nonportable shell constructs cause bin/mvn errors on Debian
Ben Caradoc-Davies created MNG-5882:
---
Summary: Nonportable shell constructs cause bin/mvn errors on
Debian
Key: MNG-5882
URL: https://issues.apache.org/jira/browse/MNG-5882
Project: Maven
Issue Type: Bug
Components: Command Line
Affects Versions: 3.3.3
Environment: debian/unstable with dash 0.5.7-4+b1 amd64
Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
2015-04-22T23:57:37+12:00)
Maven home: /home/ben/java/maven
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.1.0-2-amd64", arch: "amd64", family: "unix"
Reporter: Ben Caradoc-Davies
bin/mvn includes both local and export commands that perform assignment but do
not protect against word splitting. These cause failures on Debian when run in
a path with spaces because /bin/sh is dash which performs word splitting for
assignment in local and export commands. See discussion here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598239
"Bash and others treat 'local' (just like export, etc) differently, but it's a
known shell portability issue."
For example, in this working directory:
{noformat}
/home/ben/geoserver/src with spaces/geotools
{noformat}
{noformat}
$ mvn [options]
/home/ben/java/maven/bin/mvn: 200: local: spaces/geotools: bad variable name
[...]
{noformat}
Moving the two local commands in find_maven_basedir to their own lines leaves:
{noformat}
$ mvn [options]
/home/ben/java/maven/bin/mvn: 221: export: spaces/geotools: bad variable name
{noformat}
So the export command for MAVEN_PROJECTBASEDIR is also affected, and needs to
be moved to the following line. This is a regression because bin/mvn from Maven
3.2.5 worked just fine on Debian in this working directory. Both problems are
fixed in the attached patch.
Another workaround is to change the bin/mvn interpreter from /bin/sh to
/bin/bash.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-5882) Nonportable shell constructs cause bin/mvn errors on Debian
[
https://issues.apache.org/jira/browse/MNG-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Caradoc-Davies updated MNG-5882:
Description:
bin/mvn includes both local and export commands that perform assignment but do
not protect against word splitting. These cause failures on Debian when run in
a path with spaces because /bin/sh is dash which performs word splitting for
assignment in local and export commands. See discussion here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598239
"Bash and others treat 'local' (just like export, etc) differently, but it's a
known shell portability issue."
For example, in this working directory:
{noformat}
/home/ben/geoserver/src with spaces/geotools
{noformat}
Running bin/mvn results in:
{noformat}
$ mvn [options]
/home/ben/java/maven/bin/mvn: 200: local: spaces/geotools: bad variable name
[...]
{noformat}
Moving the two local commands in find_maven_basedir to their own lines leaves:
{noformat}
$ mvn [options]
/home/ben/java/maven/bin/mvn: 221: export: spaces/geotools: bad variable name
{noformat}
So the export command for MAVEN_PROJECTBASEDIR is also affected, and needs to
be moved to the following line. This is a regression because bin/mvn from Maven
3.2.5 worked just fine on Debian in this working directory. Both problems are
fixed in the attached patch.
Another workaround is to change the bin/mvn interpreter from /bin/sh to
/bin/bash.
was:
bin/mvn includes both local and export commands that perform assignment but do
not protect against word splitting. These cause failures on Debian when run in
a path with spaces because /bin/sh is dash which performs word splitting for
assignment in local and export commands. See discussion here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598239
"Bash and others treat 'local' (just like export, etc) differently, but it's a
known shell portability issue."
For example, in this working directory:
{noformat}
/home/ben/geoserver/src with spaces/geotools
{noformat}
{noformat}
$ mvn [options]
/home/ben/java/maven/bin/mvn: 200: local: spaces/geotools: bad variable name
[...]
{noformat}
Moving the two local commands in find_maven_basedir to their own lines leaves:
{noformat}
$ mvn [options]
/home/ben/java/maven/bin/mvn: 221: export: spaces/geotools: bad variable name
{noformat}
So the export command for MAVEN_PROJECTBASEDIR is also affected, and needs to
be moved to the following line. This is a regression because bin/mvn from Maven
3.2.5 worked just fine on Debian in this working directory. Both problems are
fixed in the attached patch.
Another workaround is to change the bin/mvn interpreter from /bin/sh to
/bin/bash.
> Nonportable shell constructs cause bin/mvn errors on Debian
> ---
>
> Key: MNG-5882
> URL: https://issues.apache.org/jira/browse/MNG-5882
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.3.3
> Environment: debian/unstable with dash 0.5.7-4+b1 amd64
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
> 2015-04-22T23:57:37+12:00)
> Maven home: /home/ben/java/maven
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.1.0-2-amd64", arch: "amd64", family: "unix"
>Reporter: Ben Caradoc-Davies
>
> bin/mvn includes both local and export commands that perform assignment but
> do not protect against word splitting. These cause failures on Debian when
> run in a path with spaces because /bin/sh is dash which performs word
> splitting for assignment in local and export commands. See discussion here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598239
> "Bash and others treat 'local' (just like export, etc) differently, but it's
> a
> known shell portability issue."
> For example, in this working directory:
> {noformat}
> /home/ben/geoserver/src with spaces/geotools
> {noformat}
> Running bin/mvn results in:
> {noformat}
> $ mvn [options]
> /home/ben/java/maven/bin/mvn: 200: local: spaces/geotools: bad variable name
> [...]
> {noformat}
> Moving the two local commands in find_maven_basedir to their own lines leaves:
> {noformat}
> $ mvn [options]
> /home/ben/java/maven/bin/mvn: 221: export: spaces/geotools: bad variable name
> {noformat}
> So the export command for MAVEN_PROJECTBASEDIR is also affected, and needs to
> be moved to the following line. This is a regression because bin/mvn from
> Maven 3.2.5 worked just fine on Debian in this working directory. Both
> problems are fixed in the attached patch.
> Another workaround is to change the bin/mvn interpreter from /bin/sh to
> /bin/bash.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] Commented: (MECLIPSE-548) MECLIPSE-442 should be reverted. Classpath container entries should come before 3rd party jars in .classpath
[ http://jira.codehaus.org/browse/MECLIPSE-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=216926#action_216926 ] Ben Caradoc-Davies commented on MECLIPSE-548: - Fabrizio, that sounds like a good solution. Documentation for the optional property should include a warning about JRE behaviour, as noted in this issue (JRE classes always loaded before 3rd party jars). Fixing this issue would be much appreciated. Kind regards, Ben. MECLIPSE-442 should be reverted. Classpath container entries should come before 3rd party jars in .classpath Key: MECLIPSE-548 URL: http://jira.codehaus.org/browse/MECLIPSE-548 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.6 Environment: all Reporter: Joe Freeman Assignee: fabrizio giustina Priority: Critical Fix For: 2.9 A patch was accepted into maven 2.6 as part of jiraMECLIPSE-442 that configures eclipse to compile with a different order than the jre will load with. This patch moved the container classpaths to the end of the classpath in eclipse. This behavior is incorrect. The JRE's jar files should come before any 3rd party libraries on the classpath because those classes will be loaded before any of the 3rd party jars and because the JRE's classes cannot be overridden by classes in a 3rd party jar. I understand why MECLIPSE-442 wanted to reverse the order so they could pick up the properties files. The best way to do this was to create properties files in the indvidual projects if he needed at run time or in the test/resources directory if it was only needed for unit testing. project resources come before everything in eclipse With this patch added to maven 2.6, we have a situation where eclipse tells us we have compiler error when maven command line compilations do not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-548) MECLIPSE-442 should be reverted. Classpath container entries should come before 3rd party jars in .classpath
[ http://jira.codehaus.org/browse/MECLIPSE-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=180415#action_180415 ] Ben Caradoc-Davies commented on MECLIPSE-548: - Thanks, Barrie. MECLIPSE-442 should be reverted. Classpath container entries should come before 3rd party jars in .classpath Key: MECLIPSE-548 URL: http://jira.codehaus.org/browse/MECLIPSE-548 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.6 Environment: all Reporter: Joe Freeman Priority: Critical Fix For: 2.8 A patch was accepted into maven 2.6 as part of jiraMECLIPSE-442 that configures eclipse to compile with a different order than the jre will load with. This patch moved the container classpaths to the end of the classpath in eclipse. This behavior is incorrect. The JRE's jar files should come before any 3rd party libraries on the classpath because those classes will be loaded before any of the 3rd party jars and because the JRE's classes cannot be overridden by classes in a 3rd party jar. I understand why MECLIPSE-442 wanted to reverse the order so they could pick up the properties files. The best way to do this was to create properties files in the indvidual projects if he needed at run time or in the test/resources directory if it was only needed for unit testing. project resources come before everything in eclipse With this patch added to maven 2.6, we have a situation where eclipse tells us we have compiler error when maven command line compilations do not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-548) MECLIPSE-442 should be reverted. Classpath container entries should come before 3rd party jars in .classpath
[ http://jira.codehaus.org/browse/MECLIPSE-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=180396#action_180396 ] Ben Caradoc-Davies commented on MECLIPSE-548: - I suspect that we need to get this assigned to someone. I will email the project lead. GeoTools is still pinned to 2.5, and so it will remain until this bug is fixed. MECLIPSE-442 should be reverted. Classpath container entries should come before 3rd party jars in .classpath Key: MECLIPSE-548 URL: http://jira.codehaus.org/browse/MECLIPSE-548 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.6 Environment: all Reporter: Joe Freeman Priority: Critical A patch was accepted into maven 2.6 as part of jiraMECLIPSE-442 that configures eclipse to compile with a different order than the jre will load with. This patch moved the container classpaths to the end of the classpath in eclipse. This behavior is incorrect. The JRE's jar files should come before any 3rd party libraries on the classpath because those classes will be loaded before any of the 3rd party jars and because the JRE's classes cannot be overridden by classes in a 3rd party jar. I understand why MECLIPSE-442 wanted to reverse the order so they could pick up the properties files. The best way to do this was to create properties files in the indvidual projects if he needed at run time or in the test/resources directory if it was only needed for unit testing. project resources come before everything in eclipse With this patch added to maven 2.6, we have a situation where eclipse tells us we have compiler error when maven command line compilations do not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-548) MECLIPSE-442 should be reverted. Classpath container entries should come before 3rd party jars in .classpath
[ http://jira.codehaus.org/browse/MECLIPSE-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=172863#action_172863 ] Ben Caradoc-Davies commented on MECLIPSE-548: - I second the rating of this bug as critical. This bug breaks Eclipse integration for GeoTools, because maven-eclipse-plugin does not honour exclusions of transitive dependencies, and GeoTools Eclipse integration relies on xml-apis provided by the JRE being compatible with xerces 2.7 and being earlier on the classpath. Yes, this sucks, but it works. To reproduce with Maven 2.0.10 (use a Java 5 JDK): (1) svn co http://svn.osgeo.org/geotools/trunk geotools-trunk (2) cd geotools-trunk (3) mvn -Dmaven.test.skip install eclipse:eclipse (4) import into Eclipse, and see modules fail to compile MECLIPSE-442 should be reverted. Classpath container entries should come before 3rd party jars in .classpath Key: MECLIPSE-548 URL: http://jira.codehaus.org/browse/MECLIPSE-548 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.6 Environment: all Reporter: Joe Freeman Priority: Critical A patch was accepted into maven 2.6 as part of jiraMECLIPSE-442 that configures eclipse to compile with a different order than the jre will load with. This patch moved the container classpaths to the end of the classpath in eclipse. This behavior is incorrect. The JRE's jar files should come before any 3rd party libraries on the classpath because those classes will be loaded before any of the 3rd party jars and because the JRE's classes cannot be overridden by classes in a 3rd party jar. I understand why MECLIPSE-442 wanted to reverse the order so they could pick up the properties files. The best way to do this was to create properties files in the indvidual projects if he needed at run time or in the test/resources directory if it was only needed for unit testing. project resources come before everything in eclipse With this patch added to maven 2.6, we have a situation where eclipse tells us we have compiler error when maven command line compilations do not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-548) MECLIPSE-442 should be reverted. Classpath container entries should come before 3rd party jars in .classpath
[
http://jira.codehaus.org/browse/MECLIPSE-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=172867#action_172867
]
Ben Caradoc-Davies commented on MECLIPSE-548:
-
Workaround for this bug is to pin your project to version 2.5:
{code}
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-eclipse-plugin/artifactId
version2.5/version
...
{code}
MECLIPSE-442 should be reverted. Classpath container entries should come
before 3rd party jars in .classpath
Key: MECLIPSE-548
URL: http://jira.codehaus.org/browse/MECLIPSE-548
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
(.classpath)
Affects Versions: 2.6
Environment: all
Reporter: Joe Freeman
Priority: Critical
A patch was accepted into maven 2.6 as part of jiraMECLIPSE-442 that
configures eclipse to compile with a different order than the jre will load
with. This patch moved the container classpaths to the end of the classpath
in eclipse. This behavior is incorrect. The JRE's jar files should come
before any 3rd party libraries on the classpath because those classes will be
loaded before any of the 3rd party jars and because the JRE's classes cannot
be overridden by classes in a 3rd party jar.
I understand why MECLIPSE-442 wanted to reverse the order so they could pick
up the properties files. The best way to do this was to create properties
files in the indvidual projects if he needed at run time or in the
test/resources directory if it was only needed for unit testing. project
resources come before everything in eclipse
With this patch added to maven 2.6, we have a situation where eclipse tells
us we have compiler error when maven command line compilations do not.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-548) MECLIPSE-442 should be reverted. Classpath container entries should come before 3rd party jars in .classpath
[ http://jira.codehaus.org/browse/MECLIPSE-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=172868#action_172868 ] Ben Caradoc-Davies commented on MECLIPSE-548: - See Nabble discussion: http://n2.nabble.com/Eclipse-integration-broken--td2631438.html MECLIPSE-442 should be reverted. Classpath container entries should come before 3rd party jars in .classpath Key: MECLIPSE-548 URL: http://jira.codehaus.org/browse/MECLIPSE-548 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.6 Environment: all Reporter: Joe Freeman Priority: Critical A patch was accepted into maven 2.6 as part of jiraMECLIPSE-442 that configures eclipse to compile with a different order than the jre will load with. This patch moved the container classpaths to the end of the classpath in eclipse. This behavior is incorrect. The JRE's jar files should come before any 3rd party libraries on the classpath because those classes will be loaded before any of the 3rd party jars and because the JRE's classes cannot be overridden by classes in a 3rd party jar. I understand why MECLIPSE-442 wanted to reverse the order so they could pick up the properties files. The best way to do this was to create properties files in the indvidual projects if he needed at run time or in the test/resources directory if it was only needed for unit testing. project resources come before everything in eclipse With this patch added to maven 2.6, we have a situation where eclipse tells us we have compiler error when maven command line compilations do not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-548) MECLIPSE-442 should be reverted. Classpath container entries should come before 3rd party jars in .classpath
[ http://jira.codehaus.org/browse/MECLIPSE-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=172863#action_172863 ] Ben Caradoc-Davies edited comment on MECLIPSE-548 at 4/14/09 2:17 AM: -- I second the rating of this bug as critical. This bug breaks Eclipse integration for GeoTools, because maven-eclipse-plugin does not honour exclusions of transitive dependencies, and GeoTools Eclipse integration relies on xml-apis provided by the JRE being compatible with xerces 2.7 and being earlier on the classpath. Yes, this sucks, but it works. To reproduce with Maven 2.0.10 (use a Java 5 JDK): (1) svn co -r32785 http://svn.osgeo.org/geotools/trunk geotools-trunk (2) cd geotools-trunk (3) mvn -Dmaven.test.skip install eclipse:eclipse (4) import into Eclipse, and see modules fail to compile was (Author: bencaradocdavies): I second the rating of this bug as critical. This bug breaks Eclipse integration for GeoTools, because maven-eclipse-plugin does not honour exclusions of transitive dependencies, and GeoTools Eclipse integration relies on xml-apis provided by the JRE being compatible with xerces 2.7 and being earlier on the classpath. Yes, this sucks, but it works. To reproduce with Maven 2.0.10 (use a Java 5 JDK): (1) svn co http://svn.osgeo.org/geotools/trunk geotools-trunk (2) cd geotools-trunk (3) mvn -Dmaven.test.skip install eclipse:eclipse (4) import into Eclipse, and see modules fail to compile MECLIPSE-442 should be reverted. Classpath container entries should come before 3rd party jars in .classpath Key: MECLIPSE-548 URL: http://jira.codehaus.org/browse/MECLIPSE-548 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.6 Environment: all Reporter: Joe Freeman Priority: Critical A patch was accepted into maven 2.6 as part of jiraMECLIPSE-442 that configures eclipse to compile with a different order than the jre will load with. This patch moved the container classpaths to the end of the classpath in eclipse. This behavior is incorrect. The JRE's jar files should come before any 3rd party libraries on the classpath because those classes will be loaded before any of the 3rd party jars and because the JRE's classes cannot be overridden by classes in a 3rd party jar. I understand why MECLIPSE-442 wanted to reverse the order so they could pick up the properties files. The best way to do this was to create properties files in the indvidual projects if he needed at run time or in the test/resources directory if it was only needed for unit testing. project resources come before everything in eclipse With this patch added to maven 2.6, we have a situation where eclipse tells us we have compiler error when maven command line compilations do not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
