Re: Maven feature request

[Karl Heinz Marbaise]

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
)
*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 *



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

Re: Best way to list artifacts in local repository?

[Alexander Bubenchikov]

Look at https://maven.apache.org/maven-indexer/

On Wed, Jan 22, 2020 at 6:44 PM Mickael Istria  wrote:

> Hi all,
>
> We're currently working on extending the soon to be Eclipse "Lemminx" XML
> Language Server with Maven smartness.
> This is an interesting and promising piece of work and we already have some
> interesting basic features working: plain XML completion validation, Maven
> Model Builder error/warning reports, properties completion, version
> validation... and the list of features is growing at a good speed.
> We rely on Maven APIs for all the Maven smartness, and we try to avoid
> non-Maven API based features.
>
> However, there is a simple case we're missing to implement properly:
> listing artifacts in local repository. We could indeed just list the
> filesystem and that would work well enough, but I'm afraid it's duplicating
> some logic that might already exist in Maven.
> So the question is: is there already some API to list content of the local
> repository as Maven artifacts?
>
> Thanks in advance,
> --
> Mickael Istria
> Eclipse IDE 
> developer, for Red Hat Developers 
>


-- 
Alexander Bubenchikov
Software developer
JetBrains
http://www.jetbrains.com
The Drive to Develop

Re: Maven feature request

[Alexander Bubenchikov]

How do you want to run tests? If the dependency is not in classpath of
running tests, but in classpath of main sources, then you just get an
NoClassDefFoundError, isn't it?

For me it looks like you need to put tests into another module,  make it
depend on main module and declare your third-party-dependency as provided.
(And provide it somehow, ofc)

On Thu, Jan 23, 2020 at 10:20 AM Paul Hammant 
wrote:

> I'm interested in your need for this. Like, why do you need this?
>
> On Thu, Jan 23, 2020 at 7: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 *
> >
>


-- 
Alexander Bubenchikov
Software developer
JetBrains
http://www.jetbrains.com
The Drive to Develop

Re: Maven feature request

[Paul Hammant]

I'm interested in your need for this. Like, why do you need this?

On Thu, Jan 23, 2020 at 7: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 *
>

Maven feature request

[Scott Wilson]

*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 *

Re: Doxia test flakiness

[Elliotte Rusty Harold]

I was hoping to fix these two issues:

https://issues.apache.org/jira/browse/DOXIATOOLS-64
https://issues.apache.org/jira/browse/DOXIATOOLS-54?filter=-1

I sent a PR for one of these, but it turned out to be against the
wrong repo. I know nothing about svn2git.

On Wed, Jan 22, 2020 at 4:41 PM Hervé BOUTEMY  wrote:
>
> On 4 Doxia Tools, 2 have been migrated: doxia-converter [1] and doxia-
> linkcheck [2], with very little activity (no release in 2 years)
> There are 2 remaining components: doxia-book-renderer and doxia-book-maven-
> plugin.
>
> Do you mean that you want to maintain these 2 components?
> Do you want us to create 2 Git repositories? Once created, are you able to 
> fill
> these with content filtered from doxia-tools svn2git mirror?
>
> Regards,
>
> Hervé
>
> [1] https://github.com/apache/maven-doxia-converter
>
> [2] https://github.com/apache/maven-doxia-linkcheck
>
> Le mercredi 22 janvier 2020, 18:12:30 CET Elliotte Rusty Harold a écrit :
> > Ping. Any progress on getting Doxia migrated into Github?
> >
> > On Mon, Dec 23, 2019 at 5:38 PM Elliotte Rusty Harold
> >
> >  wrote:
> > > Anyone working on Doxia these days? If so, your review of
> > > https://github.com/apache/maven-doxia-tools/pull/3 would be
> > > appreciated. This PR effectively disables a flaky autogenerated test.
> > >
> > > This was the best I could come up with on short notice to unblock some
> > > other bugs in Doxia. However if anyone can figure out how to fix the
> > > autogenerated test instead that would be even better. Details at
> > >
> > > https://issues.apache.org/jira/browse/DOXIATOOLS-64
> > >
> > > --
> > > 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
>


-- 
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: Doxia test flakiness

[Hervé BOUTEMY]

On 4 Doxia Tools, 2 have been migrated: doxia-converter [1] and doxia-
linkcheck [2], with very little activity (no release in 2 years)
There are 2 remaining components: doxia-book-renderer and doxia-book-maven-
plugin.

Do you mean that you want to maintain these 2 components?
Do you want us to create 2 Git repositories? Once created, are you able to fill 
these with content filtered from doxia-tools svn2git mirror?

Regards,

Hervé

[1] https://github.com/apache/maven-doxia-converter

[2] https://github.com/apache/maven-doxia-linkcheck

Le mercredi 22 janvier 2020, 18:12:30 CET Elliotte Rusty Harold a écrit :
> Ping. Any progress on getting Doxia migrated into Github?
> 
> On Mon, Dec 23, 2019 at 5:38 PM Elliotte Rusty Harold
> 
>  wrote:
> > Anyone working on Doxia these days? If so, your review of
> > https://github.com/apache/maven-doxia-tools/pull/3 would be
> > appreciated. This PR effectively disables a flaky autogenerated test.
> > 
> > This was the best I could come up with on short notice to unblock some
> > other bugs in Doxia. However if anyone can figure out how to fix the
> > autogenerated test instead that would be even better. Details at
> > 
> > https://issues.apache.org/jira/browse/DOXIATOOLS-64
> > 
> > --
> > 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

Possible interferences between Maven plugins

[Dirk Mahler]

Hi everybody,

a jQAssistant user created an issue 
(https://github.com/jQAssistant/jqa-maven-plugin/issues/35) reporting 
that if by adding the jQAssistant Maven plugin to the build section of 
his pom.xml the deployment of artifacts to a (private) repository gets 
broken.


The only explanation that I currently have for this effect is that my 
plugin pulls in a dependency that somehow becomes visible to the deploy 
plugin. My assumption so far was that plugins are isolated, is there 
something that possibly could break this, e.g. the existence of a 
extension.xml (which is the case for the jQA Maven plugin)?


Best regards and thanks in advance

Dirk

-
BUSCHMAIS GbR
Inhaber  Torsten Busch, Frank Schwarz, Dirk Mahler, Tobias Israel
Adresse  Leipziger Straße 93, 01127 Dresden
Telefon  +49 351 320923-0
Mobil +49 177 3137411
Fax  +49 351 320923-29
E-Mail   dirk.mah...@buschmais.com
Internet www.buschmais.de
-

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
Informationen. Wenn Sie diese E-Mail irrtümlich erhalten haben, bitten 
wir Sie diese E-Mail umgehend zu löschen. Das unerlaubte Kopieren sowie 
die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.


This e-mail may contain confidential or privileged information. If you 
are not the intended recipient we kindly request you to delete this 
e-mail immediately. Any unauthorized copying, disclosure or distribution 
of the material in this e-mail is strictly forbidden.

Re: Doxia test flakiness

[Elliotte Rusty Harold]

Ping. Any progress on getting Doxia migrated into Github?

On Mon, Dec 23, 2019 at 5:38 PM Elliotte Rusty Harold
 wrote:
>
> Anyone working on Doxia these days? If so, your review of
> https://github.com/apache/maven-doxia-tools/pull/3 would be
> appreciated. This PR effectively disables a flaky autogenerated test.
>
> This was the best I could come up with on short notice to unblock some
> other bugs in Doxia. However if anyone can figure out how to fix the
> autogenerated test instead that would be even better. Details at
>
> https://issues.apache.org/jira/browse/DOXIATOOLS-64
>
> --
> 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

Best way to list artifacts in local repository?

[Mickael Istria]

Hi all,

We're currently working on extending the soon to be Eclipse "Lemminx" XML
Language Server with Maven smartness.
This is an interesting and promising piece of work and we already have some
interesting basic features working: plain XML completion validation, Maven
Model Builder error/warning reports, properties completion, version
validation... and the list of features is growing at a good speed.
We rely on Maven APIs for all the Maven smartness, and we try to avoid
non-Maven API based features.

However, there is a simple case we're missing to implement properly:
listing artifacts in local repository. We could indeed just list the
filesystem and that would work well enough, but I'm afraid it's duplicating
some logic that might already exist in Maven.
So the question is: is there already some API to list content of the local
repository as Maven artifacts?

Thanks in advance,
-- 
Mickael Istria
Eclipse IDE 
developer, for Red Hat Developers 

[VOTE] Release Apache Parent POM version 23

[Hervé BOUTEMY]

Hi,
 
We solved 4 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=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: 
a72b94255c5cef7cb53700cfc53287d05361e4d73f0fcf71930c329aeb467787bcc3f7911793839a14a71d372c44e36438c2a4e66e811cead042a799b11587c1
 
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