Re: Maven feature request

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Maven feature request

Scott Wilson
Hi Paul

I write test automation and try to stick to a solid design. I find others
break solid design principles so having a <main> 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 <main> 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 <main> 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 <[hidden email]>
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 <test> 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 <main>*
> >
> > *If the scope is <main> 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 <http://linkedin.com/in/hockeyeh>*
> >
>
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <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 <[hidden email]> 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 <[hidden email]> 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 <test> 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 <main>*
>> >
>> > *If the scope is <main> 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 <http://linkedin.com/in/hockeyeh>*
>>
>>
>>
>> --
>> Elliotte Rusty Harold
>> [hidden email]



--
Elliotte Rusty Harold
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]