Re: Maven 4.0.0

[Mark Derricutt]

On 12 Nov 2017, at 23:06, Stephen Connolly wrote:

> That could end up duplicating the local repo cache... unless we default the
> cache to ~/.m2/repository anyway... otoh a concurrency safe local repo
> cache may mandate a new location... but double the downloads for inter-op
> with older Maven installs on the same machine seems not so good to me.

If we're talking restructuring the local repo, I've long wanting to separate 
out locally "mvn install"'d items from those downloaded, essentially this would 
keep ( for the most part ) local SNAPSHOTs separate from anything downloaded.

I guess what I really want there is a local releases/snaphshots repo 
separation, often it's handy to just blow away all snapshots and rebuild into a 
known state.  It does make for more complexity tho.



---
"The ease with which a change can be implemented has no relevance at all to 
whether it is the right change for the (Java) Platform for all time."  
Mark Reinhold.

Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt


signature.asc
Description: OpenPGP digital signature

[GitHub] hboutemy closed pull request #1: Fix typos in AbstractJxrReport.

[GitBox]

hboutemy closed pull request #1: Fix typos in AbstractJxrReport.
URL: https://github.com/apache/maven-jxr/pull/1
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/maven-jxr-plugin/src/main/java/org/apache/maven/plugin/jxr/AbstractJxrReport.java
 
b/maven-jxr-plugin/src/main/java/org/apache/maven/plugin/jxr/AbstractJxrReport.java
index 43b4c73..199e15a 100644
--- 
a/maven-jxr-plugin/src/main/java/org/apache/maven/plugin/jxr/AbstractJxrReport.java
+++ 
b/maven-jxr-plugin/src/main/java/org/apache/maven/plugin/jxr/AbstractJxrReport.java
@@ -474,11 +474,11 @@ protected void executeReport( Locale locale )
 }
 catch ( JxrException e )
 {
-throw new MavenReportException( "Error while generating the 
HTML source code of the projet.", e );
+throw new MavenReportException( "Error while generating the 
HTML source code of the project.", e );
 }
 catch ( IOException e )
 {
-throw new MavenReportException( "Error while generating the 
HTML source code of the projet.", e );
+throw new MavenReportException( "Error while generating the 
HTML source code of the project.", e );
 }
 }
 }


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] hboutemy commented on issue #1: Fix typos in AbstractJxrReport.

[GitBox]

hboutemy commented on issue #1: Fix typos in AbstractJxrReport.
URL: https://github.com/apache/maven-jxr/pull/1#issuecomment-343755961
 
 
   merged in 
https://github.com/apache/maven-jxr/commit/b1bc166e6335f1526ef902f49ab59b32f3475ab1
   
   thank you


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

Re: Any ETA for maven-javadoc-plugin 3.0.0?

[Mark Raynsford]

On 2017-11-12T15:15:49 +0100
"Robert Scholte"  wrote:

> MJAVADOC-475 is about replacing a parameter, which makes it as critical as  
> MJAVADOC-457.
> We just consider 3.0.0 to be THE version to be able to do a cleanup, hence  
> MJAVADOC-475 must be fixed as well.
> 
> The good news is: MJAVADOC-457 and MJAVADOC-475 are finished. I don't see  
> any deprecated parameters anymore.
> 
> MJAVADOC-499 is a too dangerous proposal for me. So I don't mind moving  
> that issue forward, it is not critical for 3.0.0, there is a workaround  
> (or preferred solution depending on who you ask) for this issue.
> 
> Which means I can prepare the release this week.
> Just need to ensure all CI servers still accept the changes.

OK, thanks!

I look forward to it.

-- 
Mark Raynsford | http://www.io7m.com



pgp71b_cipRhU.pgp
Description: OpenPGP digital signature

[GitHub] bhav0904 opened a new pull request #1: Fix typos in AbstractJxrReport.

[GitBox]

bhav0904 opened a new pull request #1: Fix typos in AbstractJxrReport.
URL: https://github.com/apache/maven-jxr/pull/1
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[VOTE] Release Apache Maven JDeprScan Plugin version 3.0.0-alpha-1

[Robert Scholte]

Hi,

This is the initial release of the Maven JDeprScan Plugin.

It is a wrapper around the jdeprscan tool, available since Java 9:
https://docs.oracle.com/javase/9/tools/jdeprscan.htm

There are zero issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MJDEPRSCAN%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1374/
https://repository.apache.org/service/local/repositories/maven-1374/content/org/apache/maven/plugins/maven-jdeprscan-plugin/3.0.0-alpha-1/maven-jdeprscan-plugin-3.0.0-alpha-1-source-release.zip

Source release checksum(s):
maven-jdeprscan-plugin-3.0.0-alpha-1-source-release.zip sha1:  
ccbed33ea3baa527b9a0cf90dbb4f9ca8bb88ef4


Staging site:
https://maven.apache.org/plugins-archives/maven-jdeprscan-plugin-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

Re: Any ETA for maven-javadoc-plugin 3.0.0?

[Robert Scholte]

MJAVADOC-475 is about replacing a parameter, which makes it as critical as  
MJAVADOC-457.
We just consider 3.0.0 to be THE version to be able to do a cleanup, hence  
MJAVADOC-475 must be fixed as well.


The good news is: MJAVADOC-457 and MJAVADOC-475 are finished. I don't see  
any deprecated parameters anymore.


MJAVADOC-499 is a too dangerous proposal for me. So I don't mind moving  
that issue forward, it is not critical for 3.0.0, there is a workaround  
(or preferred solution depending on who you ask) for this issue.


Which means I can prepare the release this week.
Just need to ensure all CI servers still accept the changes.

thanks,
Robert

On Sun, 12 Nov 2017 12:07:35 +0100, Mark Raynsford  
 wrote:



'Ello.

On 2017-11-11T14:40:16 +0100
"Robert Scholte"  wrote:


I'd hope to do a release this month. Not sure if it'll be a M2 or not,
depends if all 3.0.0 prerequisites are met.


Right.

From what I can see, only MJAVADOC-475 is not really *critical* to the
release as it's just a new feature. The other two issues, MJAVADOC-457
and MJAVADOC-499, seem to be important. The former has been fixed, and
the latter appears to be leaning towards being rejected. I would really
appreciate an M2 release if MJAVADOC-475 is going to otherwise delay
3.0.0.

If there's anything I can do to assist, I'm available. Right now,
MJAVADOC-498 would appear to prevent the deployment of any modular
project to Maven Central: If module A in the project depends
on module B, then JavaDoc cannot be generated. This would necessitate
adding a temporary workaround that submits an empty javadoc jar to
Central (otherwise the Central ruleset rejects the deployment due to
missing JavaDoc). I have some 30-40 projects that are itching to be
deployed but can't be unless I add a workaround or build and deploy a
custom version of the plugin myself. I'd obviously prefer not to have
to do that.


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

Re: Maven resolver branch consolidation

[Hervé BOUTEMY]

Hi,

I like the idea of simplification: I just factorized mavenVersion property to 
parent pom.

I have only one fear: what happens when the API changes in an incompatible way 
then we must release maven-artifact-resolver, then maven-resolver provider, 
then ant-tasks and demos.

AFAIK, this chicken and egg issue is exactly why everything was released in 3 
independent components (with associated complexity that I'd like also to 
remove)

What about creating a "withMavenProvider" module where we could put ant tasks 
and demos, which would define the mavenVersion property?
In case of such breaking change, we would just have to skip this module (and 
its sub-modules) for the API breaking release, then once the new compatible 
Maven provider is released, we could continue "the simple way"

this would give us the benefit of being simple in general, and have just 
something a little more complex in special incompatible cases.
Here, it would be "bizarre", since would bring a partial release for artifact 
resolver.

Another "bizarre effect" of this way of releasing is:
Artifact Resolver 1.1.1 will provide Ant Tasks and demos using Maven Resolver 
Provider 3.5.0, but Maven Resolver Provider 3.5.3 (or 3.6.0 or 4.0.0) will be 
the first using Artifact Resolver 1.1.1


Perhaps there is another simplification idea that would avoid this issue:
- merge demos in artifact resolver master, since demos are never really 
released
- let Ant Tasks in an independent branch (or component one day)

Regards,

Hervé

Le jeudi 9 novembre 2017, 06:35:51 CET Manfred Moser a écrit :
> Hi all,
> 
> I have started and made good progress on getting Maven resolver all into the
> master branch instead of having master, demos and ant-tasks in separate
> branches.
> 
> Details are tracked in https://issues.apache.org/jira/browse/MRESOLVER-28
> 
> All of it is now in a new branch called master-all for you to see.
> 
> I am now wondering what the next steps are. I added what I think should
> happen next in the issue in a comment and would appreciate any input on the
> current setup and next steps.
> 
> Any help would be appreciated.
> 
> manfred
> 
> 
> 
> 
> 
> -
> 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: Any ETA for maven-javadoc-plugin 3.0.0?

[Mark Raynsford]

'Ello.

On 2017-11-11T14:40:16 +0100
"Robert Scholte"  wrote:

> I'd hope to do a release this month. Not sure if it'll be a M2 or not,  
> depends if all 3.0.0 prerequisites are met.

Right.

From what I can see, only MJAVADOC-475 is not really *critical* to the
release as it's just a new feature. The other two issues, MJAVADOC-457
and MJAVADOC-499, seem to be important. The former has been fixed, and
the latter appears to be leaning towards being rejected. I would really
appreciate an M2 release if MJAVADOC-475 is going to otherwise delay
3.0.0.

If there's anything I can do to assist, I'm available. Right now,
MJAVADOC-498 would appear to prevent the deployment of any modular
project to Maven Central: If module A in the project depends
on module B, then JavaDoc cannot be generated. This would necessitate
adding a temporary workaround that submits an empty javadoc jar to
Central (otherwise the Central ruleset rejects the deployment due to
missing JavaDoc). I have some 30-40 projects that are itching to be
deployed but can't be unless I add a workaround or build and deploy a
custom version of the plugin myself. I'd obviously prefer not to have
to do that.

-- 
Mark Raynsford | http://www.io7m.com



pgpFD0e4jmvUj.pgp
Description: OpenPGP digital signature

Re: Maven 4.0.0

[Stephen Connolly]

Keep in mind, Maven is not the only pom consumer. Expression changes
outside the pom are probably fine. Expression changes inside the pom will
probably require the 4.0.0 (optional scope) feature to bring flatten Maven
plugin type features to first class core support (ie deploy the pom with
new properties resolved)

On Sun 12 Nov 2017 at 07:56, Chris Graham  wrote:

> One more: Better support for classifiers. ideally be able to reference them
> via a {$project.classifier} type of construct, esp so I can use/reference
> them in assemble transformations.
>
> This might be able to be done without bumping to V4 though.
>
>
>
> On Sun, Nov 12, 2017 at 6:41 PM, Chris Graham 
> wrote:
>
> > required:
> >  - *everything* in settings.xml can be put in a profile section in
> > settings.xml.
> >
> > I often move around/between projects and having to redo mirrors section,
> > and unable to add servers into the profile section for clarity is a pain.
> >
> > For me, it's just a matter of convienence.
> >
> > On Sat, Nov 4, 2017 at 11:20 PM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> >> The past two days, Hervé, Robert and I have been discussing our next
> >> steps.
> >>
> >> I think we have a semi-consensus which I want to bring back to the list:
> >>
> >> We keep 3.5.x as a stable branch with critical bug fixes only
> >>
> >> We switch master to 4.0.0 and start to burn down a release scope.
> >>
> >> 4.0.0 will not change the pom modelVersion
> >>
> >> The 4.0.0 scope should probably be:
> >>
> >> Required:
> >> * drop Java 7, switch codebase to Java 8 idioms (while maintaining
> binary
> >> api compatibility for plugins)
> >> * specify the classloader behaviour and fix impl to align with spec (may
> >> need a plugin flag to allow plugins to opt in to spec behaviour)
> >> * specify the extension spec
> >> * allow limited mutation of the runtime model (reducing transitive
> >> dependencies for consumers within the reactor, only for plugin goals
> that
> >> declare intent) use case: shade plugin
> >> * better CI integration hooks
> >> * nice error message for newer pom modelVersion
> >>
> >> Optional:
> >> * (damn I forgot, maybe Robert remembers)
> >> --
> >> Sent from my phone
> >>
> >
> >
>
-- 
Sent from my phone

Re: Maven 4.0.0

[Stephen Connolly]

On Sun 12 Nov 2017 at 07:41, Chris Graham  wrote:

> required:
>  - *everything* in settings.xml can be put in a profile section in
> settings.xml.
>
> I often move around/between projects and having to redo mirrors section,
> and unable to add servers into the profile section for clarity is a pain.
>
> For me, it's just a matter of convienence.
>

So one of the issues with that is multiple Maven versions.

Once we change the settings schema, we either need to have two settings
files or we block older Maven versions sharing the settings file with newer
versions.

Now maybe for 4.0.0 we move to a ~/.m4 directory or ~/.maven

That could end up duplicating the local repo cache... unless we default the
cache to ~/.m2/repository anyway... otoh a concurrency safe local repo
cache may mandate a new location... but double the downloads for inter-op
with older Maven installs on the same machine seems not so good to me.


> On Sat, Nov 4, 2017 at 11:20 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > The past two days, Hervé, Robert and I have been discussing our next
> steps.
> >
> > I think we have a semi-consensus which I want to bring back to the list:
> >
> > We keep 3.5.x as a stable branch with critical bug fixes only
> >
> > We switch master to 4.0.0 and start to burn down a release scope.
> >
> > 4.0.0 will not change the pom modelVersion
> >
> > The 4.0.0 scope should probably be:
> >
> > Required:
> > * drop Java 7, switch codebase to Java 8 idioms (while maintaining binary
> > api compatibility for plugins)
> > * specify the classloader behaviour and fix impl to align with spec (may
> > need a plugin flag to allow plugins to opt in to spec behaviour)
> > * specify the extension spec
> > * allow limited mutation of the runtime model (reducing transitive
> > dependencies for consumers within the reactor, only for plugin goals that
> > declare intent) use case: shade plugin
> > * better CI integration hooks
> > * nice error message for newer pom modelVersion
> >
> > Optional:
> > * (damn I forgot, maybe Robert remembers)
> > --
> > Sent from my phone
> >
>
-- 
Sent from my phone