Re: Profiles, builds, and repositories

[Benjamin Marwell]

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 will build
Linux, circle will build osx, etc).
And there is a release profile, which will only deploy all previous built
jars.

As long as this task cannot be solved differently, please let profiles
influence the build output.

I'm open for other strategies, of course, as I am working on another
project with native libraries.

Ben




On Sat, 25 Jan 2020, 06:38 Bernd Eckenfels,  wrote:

> 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
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Elliotte Rusty Harold 
> Gesendet: Friday, January 24, 2020 6:22:17 PM
> An: Maven Developers List 
> Betreff: Profiles, builds, and repositories
>
> 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 are not in a jar.
>
> My gut is that this is possible because profiles can change plugins
> and plugins can do pretty much anything. Assuming that's so, is there
> a way to tell from the data in the repo which profile was used to
> create a particular artifact?
>
> I'm particularly concerned about dependencies. Profiles can change
> dependencies, so the runtime and compile time classpath might depend
> on the active profile.
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Profiles, builds, and repositories

[Bernd Eckenfels]

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


--
http://bernd.eckenfels.net

Von: Elliotte Rusty Harold 
Gesendet: Friday, January 24, 2020 6:22:17 PM
An: Maven Developers List 
Betreff: Profiles, builds, and repositories

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 are not in a jar.

My gut is that this is possible because profiles can change plugins
and plugins can do pretty much anything. Assuming that's so, is there
a way to tell from the data in the repo which profile was used to
create a particular artifact?

I'm particularly concerned about dependencies. Profiles can change
dependencies, so the runtime and compile time classpath might depend
on the active profile.


--
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Parent POM version 23

[Sylwester Lachiewicz]

+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 <
> herve.bout...@free.fr> ha scritto:
>
> > 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
> > >
> > >
> >
> https://github.com/apache/maven-apache-parent/compare/apache-22...apache-23
> > >
> > > Staging repo:
> > >
> https://repository.apache.org/content/repositories/orgapacheapache-1018/
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheapache-1018/org/
> > > apache/apache/23/apache-23-source-release.zip
> > >
> > > Source release checksum(s):
> > > apache-23-source-release.zip sha512:
> > >
> >
> a72b94255c5cef7cb53700cfc53287d05361e4d73f0fcf71930c329aeb467787bcc3f791179
> > > 3839a14a71d372c44e36438c2a4e66e811cead042a799b11587c1
> > >
> > > Staging site:
> > > https://maven.apache.org/pom-archives/asf-LATEST/
> > >
> > > Guide to testing staged releases:
> > >
> https://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for at least 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [VOTE] Release Apache Parent POM version 23

[Enrico Olivelli]

+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 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
> >
> >
> https://github.com/apache/maven-apache-parent/compare/apache-22...apache-23
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/orgapacheapache-1018/
> >
> https://repository.apache.org/content/repositories/orgapacheapache-1018/org/
> > apache/apache/23/apache-23-source-release.zip
> >
> > Source release checksum(s):
> > apache-23-source-release.zip sha512:
> >
> a72b94255c5cef7cb53700cfc53287d05361e4d73f0fcf71930c329aeb467787bcc3f791179
> > 3839a14a71d372c44e36438c2a4e66e811cead042a799b11587c1
> >
> > Staging site:
> > https://maven.apache.org/pom-archives/asf-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven feature request

[Scott Wilson]

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 anything I can do to
make this work? He was using gson in this example.

Scott



On Fri, Jan 24, 2020 at 5:02 AM Elliotte Rusty Harold 
wrote:

> 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 what. Perhaps this would work if your proposed
> main scope were added to compile and run but not test? However, I
> suspect the transitive dependencies would still be needed in the
> classpath or the tests will fail with runtime NoClassDefFoundErrors
> and the like.
>
> What you want sounds a little like strict_java_deps in bazel:
> https://blog.bazel.build/2017/06/28/sjd-unused_deps.html
>
> On Thu, Jan 23, 2020 at 2:17 AM Scott Wilson  wrote:
> >
> > *Hi Robert and devs*
> >
> >
> > *I have been using maven for a few years and I LOVE it!*
> >
> >
> > *I have a feature request.*
> >
> >
> > *(1) When adding a dependency to pom.xml the default scope is everywhere*
> >
> > *ie src/main/java/*
> >
> > *and src/tst/java/...*
> >
> >
> > *(2) When adding  as the scope then the dependency can ONLY be used
> > under src/tst/java...*
> >
> > *If referencing the dependency in src/main/java/... then it will not
> > compile*
> >
> >
> > *(3) My feature request:*
> >
> > *I want the exact opposite. I'd like a new scope called *
> >
> > *If the scope is  then the dependency can ONLY be used under
> > src/main/java/...*
> >
> > *If referencing the dependency in tst/main/java/ then it will not
> > compile*
> >
> >
> > *I read up on scopes
> > (**
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
> > <
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
> >)
> > *and
> > AFAIK this is not currently supported, but I have a specific reason for
> > wanting this.
> >
> >
> > *I'd really appreciate if someone can add that for me and let me know
> when
> > it's done.*
> >
> > *Please let me know if you have any questions.*
> >
> >
> > *Regards*
> >
> > *Scott Wilson*
> >
> > *http://linkedin.com/in/hockeyeh *
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>

http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0

wait-demo
wait-demo
1.0


1.7
utf-8




com.google.code.gson
gson
2.3



junit
junit
4.11
test







org.apache.maven.plugins
maven-compiler-plugin
2.3.2

${java-version}
${java-version}
utf-8
true





org.apache.maven.plugins
maven-surefire-plugin
2.17

junit:junit

**/*Test.java


**/*AbstractTest.java



com.google.code.gson:gson








-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Parent POM version 23

[Hervé BOUTEMY]

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
> 
> https://github.com/apache/maven-apache-parent/compare/apache-22...apache-23
> 
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheapache-1018/
> https://repository.apache.org/content/repositories/orgapacheapache-1018/org/
> apache/apache/23/apache-23-source-release.zip
> 
> Source release checksum(s):
> apache-23-source-release.zip sha512:
> a72b94255c5cef7cb53700cfc53287d05361e4d73f0fcf71930c329aeb467787bcc3f791179
> 3839a14a71d372c44e36438c2a4e66e811cead042a799b11587c1
> 
> Staging site:
> https://maven.apache.org/pom-archives/asf-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for at least 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Profiles, builds, and repositories

[Robert Scholte]

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 this, but it is 
still possible.
My rule is that commandline arguments should never have effect on the generated 
artifacts (so -DskipTests might be acceptable, but -Dmaven.compiler.release=X 
not)

In the near future we might be able to fix this for the consumer-pom, but it 
won't make it reproducible from sources.

thanks,
Robert
On 24-1-2020 18:23:01, Elliotte Rusty Harold  wrote:
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 are not in a jar.

My gut is that this is possible because profiles can change plugins
and plugins can do pretty much anything. Assuming that's so, is there
a way to tell from the data in the repo which profile was used to
create a particular artifact?

I'm particularly concerned about dependencies. Profiles can change
dependencies, so the runtime and compile time classpath might depend
on the active profile.


--
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Profiles, builds, and repositories

[Elliotte Rusty Harold]

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 are not in a jar.

My gut is that this is possible because profiles can change plugins
and plugins can do pretty much anything. Assuming that's so, is there
a way to tell from the data in the repo which profile was used to
create a particular artifact?

I'm particularly concerned about dependencies. Profiles can change
dependencies, so the runtime and compile time classpath might depend
on the active profile.


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven feature request

[Elliotte Rusty Harold]

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 at 9:19 AM Scott Wilson  wrote:
>
> 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 
>  to the build path in the pom.xml. Can you take 
> a look at the attached pom and see if there's anything I can do to make this 
> work? He was using gson in this example.
>
> Scott
>
>
>
> On Fri, Jan 24, 2020 at 5:02 AM Elliotte Rusty Harold  
> wrote:
>>
>> 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 what. Perhaps this would work if your proposed
>> main scope were added to compile and run but not test? However, I
>> suspect the transitive dependencies would still be needed in the
>> classpath or the tests will fail with runtime NoClassDefFoundErrors
>> and the like.
>>
>> What you want sounds a little like strict_java_deps in bazel:
>> https://blog.bazel.build/2017/06/28/sjd-unused_deps.html
>>
>> On Thu, Jan 23, 2020 at 2:17 AM Scott Wilson  wrote:
>> >
>> > *Hi Robert and devs*
>> >
>> >
>> > *I have been using maven for a few years and I LOVE it!*
>> >
>> >
>> > *I have a feature request.*
>> >
>> >
>> > *(1) When adding a dependency to pom.xml the default scope is everywhere*
>> >
>> > *ie src/main/java/*
>> >
>> > *and src/tst/java/...*
>> >
>> >
>> > *(2) When adding  as the scope then the dependency can ONLY be used
>> > under src/tst/java...*
>> >
>> > *If referencing the dependency in src/main/java/... then it will not
>> > compile*
>> >
>> >
>> > *(3) My feature request:*
>> >
>> > *I want the exact opposite. I'd like a new scope called *
>> >
>> > *If the scope is  then the dependency can ONLY be used under
>> > src/main/java/...*
>> >
>> > *If referencing the dependency in tst/main/java/ then it will not
>> > compile*
>> >
>> >
>> > *I read up on scopes
>> > (**https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
>> > )
>> > *and
>> > AFAIK this is not currently supported, but I have a specific reason for
>> > wanting this.
>> >
>> >
>> > *I'd really appreciate if someone can add that for me and let me know when
>> > it's done.*
>> >
>> > *Please let me know if you have any questions.*
>> >
>> >
>> > *Regards*
>> >
>> > *Scott Wilson*
>> >
>> > *http://linkedin.com/in/hockeyeh *
>>
>>
>>
>> --
>> Elliotte Rusty Harold
>> elh...@ibiblio.org



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven feature request

[Paul Hammant]

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 for "what is our prod code vs
test code".

And in that we-ship-a-lib-that-uses-selenium space, then perhaps there
you're wanting to wrap WebElement. I do so for FluentSelenium -
https://github.com/SeleniumHQ/fluent-selenium/blob/master/java/src/main/java/org/seleniumhq/selenium/fluent/FluentWebElement.java
- but even then I make a getWebElement() for situations where they *really
frickin want to*.

If not a we-ship-a-lib-that-uses-selenium case, then I'm not following -
Selenium is classically a test-scoped thing.

If you're worried about hacker teams quietly promoting selenium-java from
test-scope to no-scope and then those jars quietly being zipped into the
(say) WAR file that heads to production, just use mvn-dependency:tree and
python to discover that's happened, or unzip the uber/shade jar to look for
verbotten classes, and then fail the CI build.



On Thu, Jan 23, 2020 at 11:00 PM Scott Wilson  wrote:

> Hi Paul
>
> I write test automation and try to stick to a solid design. I find others
> break solid design principles so having a  scope will prevent people
> from breaking some basic principles.
>
> For example, if using Selenium I've seen multiple people expose WebElement
> in a public method (that should be a private implementation detail). This
> is just an example of horrible implementation I've seen multiple people do
> without thinking. The new  scope will not prevent that however it
> will prevent the following.
>
> I've seen people create src/tst/java/helloworld/MyTest.java which accesses
> a WebElement directly in their Junit / TestNG class. The new  scope
> will prevent stuff like that from happening. What they should really do is
> create src/main/java/helloworld/MyPage.java which implements the
> functionality using WebElement, then get an instance of MyPage from their
> src/tst/java/helloworld/MyTest.java.
>
> That is just one obvious example but I've seen other poor implementations
> using other dependencies which are as obvious what is good vs bad design
> unless this principle is understood.
>
> Scott
>
>
>
> On Wed, Jan 22, 2020 at 11:43 PM Karl Heinz Marbaise 
> wrote:
>
> > Hi,
> >
> > On 23.01.20 00:59, Scott Wilson wrote:
> > > *Hi Robert and devs*
> > >
> > >
> > > *I have been using maven for a few years and I LOVE it!*
> > >
> > >
> > > *I have a feature request.*
> > >
> > >
> > > *(1) When adding a dependency to pom.xml the default scope is
> everywhere*
> > >
> > > *ie src/main/java/*
> > >
> > > *and src/tst/java/...*
> > >
> > >
> > > *(2) When adding  as the scope then the dependency can ONLY be
> used
> > > under src/tst/java...*
> > >
> > > *If referencing the dependency in src/main/java/... then it will not
> > > compile* >
> > >
> > > *(3) My feature request:*
> > >
> > > *I want the exact opposite. I'd like a new scope called *
> > >
> > > *If the scope is  then the dependency can ONLY be used under
> > > src/main/java/...*
> > >
> > > *If referencing the dependency in tst/main/java/ then it will not
> > > compile*
> >
> > This would result in the problem that you neever can run / compile your
> > unit- and integration tests cause something is missing on the classpath
> > so in result your project would be unusable...
> >
> >
> >
> > >
> > >
> > > *I read up on scopes
> > > (**
> >
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
> > > <
> >
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
> > >)
> > > *and
> > > AFAIK this is not currently supported, but I have a specific reason for
> > > wanting this.
> >
> > It would be great if you could shared this with us
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> >
> > >
> > >
> > > *I'd really appreciate if someone can add that for me and let me know
> > when
> > > it's done.*
> > >
> > > *Please let me know if you have any questions.*
> > >
> > >
> > > *Regards*
> > >
> > > *Scott Wilson*
> > >
> > > *http://linkedin.com/in/hockeyeh *
> > >
> >
>

Re: Maven feature request

[Elliotte Rusty Harold]

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 what. Perhaps this would work if your proposed
main scope were added to compile and run but not test? However, I
suspect the transitive dependencies would still be needed in the
classpath or the tests will fail with runtime NoClassDefFoundErrors
and the like.

What you want sounds a little like strict_java_deps in bazel:
https://blog.bazel.build/2017/06/28/sjd-unused_deps.html

On Thu, Jan 23, 2020 at 2:17 AM Scott Wilson  wrote:
>
> *Hi Robert and devs*
>
>
> *I have been using maven for a few years and I LOVE it!*
>
>
> *I have a feature request.*
>
>
> *(1) When adding a dependency to pom.xml the default scope is everywhere*
>
> *ie src/main/java/*
>
> *and src/tst/java/...*
>
>
> *(2) When adding  as the scope then the dependency can ONLY be used
> under src/tst/java...*
>
> *If referencing the dependency in src/main/java/... then it will not
> compile*
>
>
> *(3) My feature request:*
>
> *I want the exact opposite. I'd like a new scope called *
>
> *If the scope is  then the dependency can ONLY be used under
> src/main/java/...*
>
> *If referencing the dependency in tst/main/java/ then it will not
> compile*
>
>
> *I read up on scopes
> (**https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
> )
> *and
> AFAIK this is not currently supported, but I have a specific reason for
> wanting this.
>
>
> *I'd really appreciate if someone can add that for me and let me know when
> it's done.*
>
> *Please let me know if you have any questions.*
>
>
> *Regards*
>
> *Scott Wilson*
>
> *http://linkedin.com/in/hockeyeh *



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org