Hi,
maven-site-plugin has a dependency on sisu-inject-plexus [1] but it
doesn't seem to be used. The project still builds and the tests pass
without it.
Is it safe to assume it can be removed?
Emmanuel Bourg
[1]
https://github.com/apache/maven-site-plugin/blob/maven-site-plugin-
eproducibility.
> (Another joke) By the way, what do you do with npm packages?
I leave this mess to the JS folks :)
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
is broken in
a core library like maven-shared-utils).
> 3) (Joker) What is the overall CO2 footprint of distros like
> these? I believe you did not use Apple M1 for this work... :)
Probably a tiny fraction of what bitcoin mining, Travis CI and
Youtube/Netflix 4K videos generate ;)
Em
: Maven was the easy part, Gradle and Kotlin are many leagues above
in term of circular dependencies and headache. We have been trying to
bootstrap Kotlin for 2 years in Debian and haven't found the right path yet.
Emmanuel Bourg
On 18/11/2020 21:29, Björn Höfling wrote:
> Dear Maven De
rt with a verb, that would no longer be
true with the proposed 'sources' and 'resources' phases. Since it isn't
that common to invoke these phases directly from the command line maybe
the longer name could be retained to preserve the consistency
(gener
t variable I don't
think that's necessary, otherwise it would be nice to be able to invoke
Maven with:
mvn package -Dproject.build.outputTimestamp=$SOURCE_DATE_EPOCH
and this means supporting a timestamp formatted as second
of using a property that can be inherited. In a multi
modules project it's only necessary to define the timestamp once in the
root pom. Parent poms deployed to Maven Central will never include a
timestamp and there is no risk of affecting other projects deriving from
the pom.
t;
+1, some kind of support for SOURCE_DATE_EPOCH would be nice. Either
this (but maybe with only one property supporting both formats) or by
overriding automatically the property when SOURCE_DATE_EPOCH is set.
Emmanuel Bourg
-
To
imestamp).
> once again, war files taken apart for web servers, who looks at timestamp in
> zip files?
archive timestamps are just the tip of the iceberg. There are more
visible timestamps elsewhere, for example in the javadoc headers, in
.properties
this is a nice feature? I can only see the downside of
child projects having a timestamp clamped in the past and leaving the
developers clueless about the reason. This would be especially bad if a
widely used parent pom like org.sonatype.oss:oss-parent or
org.apache:apache
ISO-8601 format
>
>
>
> 2019-10-02T08:04:00Z
>
>
You may want to specify explicitly that the timestamp must be formatted
with the UTC timezone (as in your example).
Would it be possible to prevent this property from
Le 03/10/2019 à 16:54, Karl Heinz Marbaise a écrit :
> Hm.. first Java 7 is out for eight years now (2011) (End of live) and
> has no public updates for security/bug fixes etc. since 2015
RedHat still maintains OpenJDK 7 until June 2020 [1].
Emmanuel Bourg
[1]
https://access.redh
How do you plan to capture the elements of the build environment
necessary to build identical artifacts (JDK used, command line
parameters) ? As project properties too?
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@
e file deployed
along the pom and capturing the build environment. What Maven needs then
is a command line parameter to force a specific build time (and/or
support for the SOURCE_DATE_EPOCH environment variable).
Emmanuel Bourg
-
n
> core itself can be built in a reproducible way!
An important milestone on a very long journey. Well done!
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
e network.
It's impossible to download dependencies or plugins from Maven Central.
That's why we recreate a Maven repository in /usr/share/maven-repo/ and
instruct Maven to fetch the dependencies there instead of Maven Central
when building a Debian package. This repository is populated by
gt; Even though we as Maven developers don't like the wrapper, the community
> is asking for it, so we're seriously considering to add it as part of
> Maven Core.
The wrapper would have no significant impact on the Debian packaging, we
just remove it before assembling the source packag
)
and removing the Ant script is likely to be disrupting.
Emmanuel Bourg
Le 26/02/2015 19:15, Igor Fedorenko a écrit :
> Sorry if this is a dup of a recent discussion, but I couldn't find
> anything so here it goes.
>
> Why do we use ant to run Maven CI build at https://builds
18 matches
Mail list logo
