There are cases where profiles must steer the build output though, although
they are rare.
For example, look at lmdb-native on GitHub. lmdb uses lots of native
methods. As they are building the jars containing the .so files from the
very same sources, they control the ci using profiles (Jenkins
Hello,
Yes profiles can severely affect the content of a build artifact and there is
no way to tell the used profile in the Maven repo. This is generally the reason
why it should not be used to influence the released build artifacts and can
also not be relied upon.
Gruss
Bernd
--
+1 (non binding)
pt., 24 sty 2020, 23:10 użytkownik Enrico Olivelli
napisał:
> +1 (non binding)
> I have checked the diff on github, the changes are consistent with the
> descriptions on JIRA
>
> Thank you Hervé
>
> Enrico
>
> Il giorno ven 24 gen 2020 alle ore 22:36 Hervé BOUTEMY <
>
+1 (non binding)
I have checked the diff on github, the changes are consistent with the
descriptions on JIRA
Thank you Hervé
Enrico
Il giorno ven 24 gen 2020 alle ore 22:36 Hervé BOUTEMY <
herve.bout...@free.fr> ha scritto:
> here is my +1
>
> I need more votes...
>
> Regards,
>
> Hervé
>
> Le
Thank you for replying Elliotte,
I hired someone on Fiverr to try to figure out a workaround for this. He
was not successful however he may have been close. He added <
*classpathDependencyExcludes*> to the build path in the pom.xml. Can you
take a look at the attached pom and see if there's
here is my +1
I need more votes...
Regards,
Hervé
Le mercredi 22 janvier 2020, 16:17:24 CET Hervé BOUTEMY a écrit :
> Hi,
>
> We solved 4 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250
> rsion=12346503=Text
>
>
It is even worse.
Are you familiar with Springboot?
It has a property for a lot of versions, for both dependencies and plugins.
The idea is that you can override it in your own pom file.
However, you can do it from commandline as well!
When using the maven-release-plugin it is harder to achieve
Is it possible for a profile to materially affect what gets installed
in a repository, particularly the central repo?
I'm not concerned about minutiae like builds times and other details
the reproducible build work is concerned with. I'm talking about more
major things like which classes are and
That's not going to work for the same reason.
classpathDependencyExcludes removes a jar from the classpath, and you
need the jar in the classpath, at least in most circumstances. A
custom checkstyle rule might solve your problem, but you can't do it
by changing the classpath.
On Fri, Jan 24, 2020
Selenium co-creator here (albeit v1),
WebElement is pubic API and not impl-detail. If you're making a library
for downstream *testing* teams to use, then selenium-java jumps from
test-scope to prod-scope of course and is now a transitive dep. Many
build/test tools makers are in the same place
That's a really interesting idea and I can see the use of it. I'm not
sure it fits with how scopes work in Maven or classpaths in Java
though. A scope generally defines which jars are and are not added to
the classpaths of which goals/plugins/stages, not which parts of the
source tree can see
11 matches
Mail list logo
