Re: Using Maven JXR as base for report plugin

[Plamen Totev]

Hi Enrico,

Thanks for the reply.

On 24.10.2019 г. 0:57, Enrico Olivelli wrote:
> Il mer 23 ott 2019, 20:29 Plamen Totev  ha
> scritto:
>
>> Hi,
>>
>> I would like to create plugin that generates test coverage report.
> Yes, it my have sense.
>
> As far as I know we do not have a standard way to provide extensions to
> plugins, if anyone on the list has some suggestion please chime in,
> otherwise I would go to make the class name (JavaCodeTransform)
configurable
> as a mojo parameter

I don't have the plugin in mind. The plugin contains two modules -
maven-jxr and maven-jxr-plugin. I would like to use the former to
generate the HTML report but use it in my own plugin. Having the option
to annotate the reports made by JXR plugin might have value but it is
outside the scope of what I want to do.

What I have in mind is to modify JavaCodeTransform to make it
extensible(or plugable). The way it works now is to use a chain of
filters to generate the markup, but this chain is hard-coded. For
example you can't easily wrap a single line inside span tag. The filters
are implemented as private methods inside JavaCodeTransfor. A simple
change as making them protected would allow classes that extend
JavaCodeTransform to modify the generated markup.

>> Or it will be better to just create my own implementation using code from
>> JavaCodeTransform
>>
> If you mean 'forking' the plugin I think it won't be a good idea, as your
> fork won't receive updates from the community version
Not the entire code base, only JavaCodeTransform .

Regards,
Plamen Totev

p.s. Enrico, sorry for spamming you with personal mail. I need to pay more
attention to how the "reply" button works :)

Using Maven JXR as base for report plugin

[Plamen Totev]

Hi,

I would like to create plugin that generates test coverage report. I 
know that there are existing plugins for that, but I want the report to 
include not only line coverage but also other data such as mutation 
coverage (and maybe some code quality issues). Also I want to be able to 
generate report only for the changed lines in the last commit. To best 
of my knowledge there is no existing plugin that does that in single report.


To create such report I need to generate HTML files from the Java 
sources files and annotate the lines with the data from the report. 
Maven JXR is great for generating HTML files but unfortunately the class 
that is responsible for generating the HTML for a single Java class 
(JavaCodeTransform) is not extensible.


Do you think it would make sense to refactor it to be extensible and 
make the filters plugable so the output can be customized? Or it will be 
better to just create my own implementation using code from 
JavaCodeTransform?


Regards,
Plamen Totev


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

Re: [maven-jenkins-lib] branch master updated: Add Java 11 to defaults

[Plamen Totev]

Speaking of making the plugins Java 11 ready maybe we should update
the Plexus Parent POM as some of the plugins are not compatible with
Java 11 (Enforcer plugin in particular) and that blocks the CI builds
of some Plexus projects. What do you think?

Regards,
Plamen Totev
On Wed, Oct 3, 2018 at 7:41 PM Robert Scholte  wrote:
>
> I don't think we will get a lot of *new* reds, only those related to ASM.
>
> And this is probably the time to make all projects Java 11 ready, the
> first complaints are already coming in.
>
>
> On Wed, 03 Oct 2018 10:56:28 +0200, Olivier Lamy  wrote:
>
> > hehe we may see a lot of red :)
> >
> > On Wed, 3 Oct 2018 at 15:46,  wrote:
> >
> >> This is an automated email from the ASF dual-hosted git repository.
> >>
> >> rfscholte pushed a commit to branch master
> >> in repository https://gitbox.apache.org/repos/asf/maven-jenkins-lib.git
> >>
> >>
> >> The following commit(s) were added to refs/heads/master by this push:
> >>  new 097a623  Add Java 11 to defaults
> >> 097a623 is described below
> >>
> >> commit 097a623bb5c3f24e94f24a86f83e8b272a1aae61
> >> Author: rfscholte 
> >> AuthorDate: Wed Oct 3 07:46:15 2018 +0200
> >>
> >> Add Java 11 to defaults
> >> ---
> >>  vars/asfMavenTlpPlgnBuild.groovy | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/vars/asfMavenTlpPlgnBuild.groovy
> >> b/vars/asfMavenTlpPlgnBuild.groovy
> >> index dc07d6e..cf0bde1 100644
> >> --- a/vars/asfMavenTlpPlgnBuild.groovy
> >> +++ b/vars/asfMavenTlpPlgnBuild.groovy
> >> @@ -33,7 +33,7 @@ def call(Map params = [:]) {
> >>
> >>  // now determine the matrix of parallel builds
> >>  def oses = params.containsKey('os') ? params.os : ['linux',
> >> 'windows']
> >> -def jdks = params.containsKey('jdks') ? params.jdks :
> >> params.containsKey('jdk') ? params.jdk : ['7','8','9','10']
> >> +def jdks = params.containsKey('jdks') ? params.jdks :
> >> params.containsKey('jdk') ? params.jdk : ['7','8','9','10','11']
> >>  def jdkMin = jdks[0];
> >>  def mavens = params.containsKey('maven') ? params.maven :
> >> ['3.2.x','3.3.x','3.5.x']
> >>  // def failFast = params.containsKey('failFast') ? params.failFast
> >> :
> >> true
> >>
> >>
>
> -
> 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: Working with branches related to issue - Simplyfying work

[Plamen Totev]

Hi,

Great work and thanks for sharing - it is really useful. I was unaware
of `--force-with-lease` option and it is nice to know.

Actually maybe you know that but I want to share it just in case. If
you name your script git-pushwithlease, make it executable and place
it in the $PATH, then you can call it with:

git pushwithlease

You can read more here - https://www.atlassian.com/blog/git/extending-git

Regards,
Plamen Totev
On Sun, Jul 22, 2018 at 1:30 PM Karl Heinz Marbaise  wrote:
>
> Hi,
>
> I have wrote up a conclusion about my currently working scripts to make
> my life easier...
>
> If someone is interested in take a look at:
>
> https://blog.soebes.de/blog/2018/07/21/automate-it-part-i/
>
> suggestiongs / ideas are always welcome...
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> 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

Making the Sonatype Plexus GitHub Repositories Read Only

[Plamen Totev]

Hi,

There a couple of Plexus related repositories hosted at the Sonatype
GitHub account (https://github.com/sonatype/plexus-compiler for
example). Those repositories are not maintained and out of date. But
they appear on the top of the google results and that causes some
confusion. There are links to the new repositories but I think it
would be even better if those repositories are archived (made read
only). What do you think? The operation is reversible - they can be
made writable again if there is a need to do so.

Also if nobody objects  I would like to contact GitHub support to
check if we can make the codehaus-plexus repositories regular ones
(they appear as forks now). That would help with them being more
easily identified as the canonical repositories.

Regards,
Plamen Totev

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

Re: Releasing Plexus Archiver 3.6.1 and plexus IO 3.0.1

[Plamen Totev]

Sorry, the correct Plexus Archiver version is 3.6.0

On Sat, Apr 14, 2018 at 9:50 AM, Plamen Totev <plamen.iv.to...@gmail.com> wrote:
> Hi,
>
> I would like to prepare a release for Plexus Archiver 3.6.1 [1] and
> Plexus IO 3.0.1[2]. There are a couple of bug fixes and support for
> modular JAR archive is introduced. If there are no objections on the
> opened pull requests I'll merge them. Also I'll update the
> dependencies. But that is far as I can go as I don't have permissions
> to publish the artifacts. Is there any volunteer to make the releases?
>
> Regards,
> Plamen Totev
>
> [1] https://github.com/codehaus-plexus/plexus-archiver/milestone/11
> [2] https://github.com/codehaus-plexus/plexus-io/milestone/2

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

Releasing Plexus Archiver 3.6.1 and plexus IO 3.0.1

[Plamen Totev]

Hi,

I would like to prepare a release for Plexus Archiver 3.6.1 [1] and
Plexus IO 3.0.1[2]. There are a couple of bug fixes and support for
modular JAR archive is introduced. If there are no objections on the
opened pull requests I'll merge them. Also I'll update the
dependencies. But that is far as I can go as I don't have permissions
to publish the artifacts. Is there any volunteer to make the releases?

Regards,
Plamen Totev

[1] https://github.com/codehaus-plexus/plexus-archiver/milestone/11
[2] https://github.com/codehaus-plexus/plexus-io/milestone/2

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

Re: Maven Core / MNG-6362 README.md / CONTRIBUTION.md

[Plamen Totev]

That is great idea.

On Tue, Feb 20, 2018 at 9:16 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:

> 2. how can we test .github/pull_request_template? The idea seems interesting

I don't know if you can. But the way it works is pretty simple. When
you create a pull request the text box will be pre-populated with the
content of the pull_request_template.md file.

Regards,
Plamen Totev

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

Re: main-class + module-version

[Plamen Totev]

Hi,

I've done some work on implementing `PlexusArchiver` that creates
modular JAR files using the JDK `jar` tool (`ToolProvider`)[1]. It is
still work in progress but I wanted to ask for you opinion - if there
are no objections I'll polish it(fix the code formatting, implement the
TODO items, etc) and would like eventually to merge it in master. Here
are some key points:

* It requires Java 9. This of course is not the minimum required version
for the rest of the archivers, but `java.util.spi.ToolProvider` is
introduced in Java 9. I'll fix the source and target to be 7, but it
will still require Java 9 to compile and currently Plexus Archiver does
not compile on Java 9. This is easy to fix - requires only update of
some of the plugins to yet to be released versions.

* A new class is added `ModularJarArchiver`. This would allow a "normal"
JARs to be created on Java 7 using `JarArchiver` while modular JARs will
require Java 9 (I don't think this is an issue as you need Java 9 to
compile modules anyway).

* `ModularJarArchiver` uses `JarArchiver` to create a "normal" JAR file
and then uses the JDK `jar` tool to update it to modular one. This may
require some additional work during the build compared to creating the
archive using only the `jar` tool, but `JarArchiver` provides some nice
additional features not available in the `jar` tool(such as not
re-compressing the zip files, generating manifest entries, etc).

What do you think? Any objections to implement it this way? I think this
is better approach than my previous attempt[2].

Regards,
Plamen Totev

[1] 
https://github.com/plamentotev/plexus-archiver/commit/b124aceb3f6a912a9dca44f5d14b9f3f2919bc6d
[2] https://github.com/codehaus-plexus/plexus-archiver/pull/75

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

Re: Plan for releasing Maven core

[Plamen Totev]

Hi,



On Wed, Jan 31, 2018 at 7:40 PM, Hervé BOUTEMY  wrote:
> I must confess that I don't understand G+ nor Facebook buttons result

Facebook might show in your news feed that you've liked the link
(https://maven.apache.org/pom/maven). Given the fact that is not the
page where the button is located I'm not 100% sure if it even works at
all. As for G+ I also have no idea at all.

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

Re: main-class + module-version

[Plamen Totev]

Hi Robert,

On 1/15/2018 10:10 PM, Robert Scholte wrote:
> Hi Plamen,
>
> Alan Bateman has provided some valuable information:

Thank you for sharing this. It's really helpful.

On 1/15/2018 10:10 PM, Robert Scholte wrote:
1. MR JARs weren't mentioned. The jar tool does validation to ensure 
that the API provided by the classes in the JAR file is the same for all 
versions.


Validation is indeed something I haven't dig in yet. It is interesting 
to know what is the impact of Maven not doing validation of modular JAR 
files.


On 1/15/2018 10:10 PM, Robert Scholte wrote:
2. The Module, ModulePackages, and ModuleMainClass class file attributes 
are specified in the JVMS. ASM supports them so the Archiver could use 
that. The ModulePackages attribute is optional. If this attribute is not 
present then the JAR file will be scanned to get the set of packages in 
the module.


If the JAR is scanned when ModulePackages is not present then for the 
time being is ok to not implement it.


On 1/15/2018 10:10 PM, Robert Scholte wrote:
The ModuleTarget, ModuleResolution, and ModuleHashes class file 
attributes are JDK-specific so you won't find these in the JVMS. The 
ModuleTarget attribute is documented in JEP 261, the others aren't there 
yet but ASM has support in org.objectweb.asm.commons for these 
attributes so you should be okay.


All of those could be set with ASM (I think) but setting them is the 
easy part. Calculating the hashes for ModuleHashes will require some 
work though.


On 1/15/2018 10:09 PM, Andreas Sewe wrote:
> Also, if two separate tools modify the JAR, the goal of reproducible
> builds is again a bit harder to accomplish. So, please try to use an
> internal, written-in-Java solution if possible.

This is a valid point. I don't think it would be possible to set the 
entries timestamps using the JDK jar tool. But a bit harder does not 
mean impossible. It could be achieved by "post-processing" the resulting 
jar file.


Another point I think we should have in mind is the fact that every time 
the class format version is increased we should update the ASM library 
and release a new version of the JAR plugin otherwise the build will 
fail. Also the users should update the JAR plugin version. That may 
prove to be a bit inconvenient.


From my point of view the trade-off is ease of maintainability vs 
flexibility and control.


Regards,
Plamen Totev

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

Re: main-class + module-version

[Plamen Totev]

Hi,

On Mon, Jan 15, 2018 at 8:23 PM, Robert Scholte <rfscho...@apache.org> wrote:
> So maybe we simply have to split it up into smaller pieces.
> I think we can already make people happy by adding the version to the
> module-info file, assuming all other added features are actually nice to
> haves.

I guess you're right. We already have the version and main class[1] -
I'll update the PR so it compiles and passes the tests.

As for the version - the module version could be set by the compiler
as well. I was thinking that maybe it would be nice if the compiler
plugin passes the project version to the Java compiler.

Regards,
Plamen Totev

[1] https://github.com/codehaus-plexus/plexus-archiver/pull/75

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

Re: main-class + module-version

[Plamen Totev]

Hi,

On 12/20/2017 9:53 PM, Robert Scholte wrote:


Based on this message it seems worth implementing a JarToolArchiver, 
using the jar tool via the ToolProvider[1]
I hope it can still be a org.codehaus.plexus.archiver.Archiver, 
otherwise I'll contact the openjdk team about the details of the 
specifications. I don't think we need them all, good to know the reason 
for the extra files.


So I did some experiments and definitely it is possible to implement it 
as org.codehaus.plexus.archiver.Archiver. I think it would be best to 
reuse JarArchiver to create the  non-modular JAR file and then use the 
JDK jar tool to update it to modular JAR file. The downside of this 
approach is that it involves additional work(there is some performance 
penalty). The JDK jar tool updates files the same as way Plexus Archiver 
- creates new file, copies the old entries and adds the new ones. Do you 
think this is really an issue? I think for small JAR files the 
difference would not be noticeable.


Of course we could create the jar file directly using only the JDK jar 
tool. But the Plexus Archiver is quite advanced tool compared to it. If 
we have to implement all of its functionality using only the JDK jar 
tool, it would be easier to update the module descriptors using asm (IMHO).


About the ToolProvider - maybe I'm missing something but it is available 
only for Java 9 and does not allow the use of tool chains, does it?


Regards,
Plamen Totev

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

Re: plexus-archiver / plexus-util Issue

[Plamen Totev]

Hi,

On 12/28/2017 10:16 PM, Karl Heinz Marbaise wrote:
> Hi,
>
> On 28/12/17 20:46, Stephen Connolly wrote:
>> But shouldn’t we be copying the last modified time stamp always anyway
>
> I'm the same opinion...but that means in consequence that the test in
> plexus-archiver is not correct...cause it's waiting for a change in the
> last-modified time ...
>
> Hm...
>
> Kind regards
> Karl Heinz Marbaise
>
>

Plexus Archiver tests are using file copy operation to change the
"last modified" timestamp of a file. This of course is not a perfect
approach but I don't think there was better one pre-Java 7. But now as
Java 7 is the minimum required version, there is
Files#setLastModifiedTime that does better job. I've created a PR that
changes the incompatible code[1]. It will allow the update of Plexus
Utils to 3.1.0 as well.

> After I have changed that and only use
>
> public static File copy( File source, File target )
> throws IOException
> {
> Path copy = Files.copy( source.toPath(), target.toPath(),
>StandardCopyOption.REPLACE_EXISTING,
>LinkOption.NOFOLLOW_LINKS );
> return copy.toFile();
> }
>
> it looks like working (see branch issue-fix):
>
> What Do you think?

The Plexus Archiver tests were not using `copy` for its intended
purpose so the decision if the file attributes are copied should not
be based on their usage. To me it makes more sense to copy the
attributes, although copying the last modified timestamp may surprise
some evelopers (like me for example) as `cp` on Linux updates the last
modified timestamp of the copy.

Regards,
Plamen Totev

[1]  https://github.com/codehaus-plexus/plexus-archiver/pull/77

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

Re: Maven site edit next steps

[Plamen Totev]

Hi,

I actually just noticed that the `apache-5` tag is not fixed. Is that on
purpose? As result GitHub cannot compare the difference between
6 and 5[1] (the last link in the table). It says they don't have
anything in common(if the tag is not fixed that is to be expected).

Also I have noticed that the pom.xml at `apache-5` tag does have very
"interesting" content. The version says "6-SNAPSHOT" instead of "5".
Maybe the tag points to commit after the release?

Regards,
Plamen Totev

[1] 
https://github.com/apache/maven-apache-parent/compare/apache-5...apache-6



On 1/10/2018 9:11 AM, Hervé BOUTEMY wrote:

thank you Plamen: you helped me find my mistake = the versions order in the
GitHub url is not the same as GitWeb (prev...current in GitHub and
current in GitWeb...)

now the page seems good:
http://maven.apache.org/pom-archives/asf-LATEST/

Regards,

Hervé

Le mardi 9 janvier 2018, 18:59:14 CET Plamen Totev a écrit :

Hi,

On 1/9/2018 3:25 AM, Hervé BOUTEMY wrote:

I tried to integrate both [1], with GitWeb as "diff" and GitHub as
"commits". But the GitHub comparison does not work well: then I put it
only on HEAD.

I don't know if this is due to my recent rework of tags for the repo, but
GitHub does not recognise any tag on this maven-apache-parent repo.
Perhaps
there is a cache that will be reworked in a few days, since the rework
happened also for maven-acr-plugin and the link works

Any idea?


I wouldn't be surprised if there is a cache - the tags are not
supposed to change under normal circumstances. Anyway now everything
seems to work. Here are some examples:

* The commits between the latest release and HEAD (I believe
asf-LATEST points to wrong URL - HEAD...apache-18 instead of
apache-18...HEAD):
https://github.com/apache/maven-apache-parent/compare/apache-18...HEAD
* The commits between apache-18 and apache-17:
https://github.com/apache/maven-apache-parent/compare/apache-17...apache-18

I guess the tags are now updated so it should work for you as well.

Regards,
Plamen Totev

p.s. Hervé, excuse me for the spam. The first message was intended for
the group. I'm using a new mail client and I've just noticed that when
I hit reply the "To" field is set to the sender not the group. I hope
I'll get used to it quickly - don't want to spam you anymore :)

On Tue, Jan 9, 2018 at 3:25 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:

thank you Plamen: useful answer, as usual

I like both GitWeb and GitHub displays: both are useful, but for different
purpose

I tried to integrate both [1], with GitWeb as "diff" and GitHub as
"commits". But the GitHub comparison does not work well: then I put it
only on HEAD.

I don't know if this is due to my recent rework of tags for the repo, but
GitHub does not recognise any tag on this maven-apache-parent repo.
Perhaps
there is a cache that will be reworked in a few days, since the rework
happened also for maven-acr-plugin and the link works

Any idea?

Regards,

Hervé

[1] http://maven.apache.org/pom-archives/asf-LATEST/

Le dimanche 7 janvier 2018, 20:45:28 CET Plamen Totev a écrit :

Hi,

On Fri, Jan 5, 2018 at 9:33 AM, Hervé BOUTEMY <herve.bout...@free.fr>

wrote:

- notice for parent poms: with Subversion, we had a cool feature which
was
the pom.xml diff from version to version published in the documentation
page [1]. Does somebody have an idea on how we could do something
equivalent with git?


Here are example links for Git Web (the software used by
gitbox.apache.org):

* To view maven-acr-plugin project's pom.xml file at specific tag
(maven-acr-plugin-1.1) -
https://gitbox.apache.org/repos/asf?p=maven-acr-plugin.git;a=blob;f=pom.x
ml; hb=maven-acr-plugin-1.1 * To view the difference for pom.xml file
between maven-acr-plugin-1.1 and maven-acr-plugin-1.0 -
https://gitbox.apache.org/repos/asf?p=maven-acr-plugin.git;a=blobdiff;f=p
om. xml;hb=maven-acr-plugin-1.1;hpb=maven-acr-plugin-1.0

For GitHub the links are:

*
https://github.com/apache/maven-acr-plugin/blob/maven-acr-plugin-1.1/pom.
xm
l *
https://github.com/apache/maven-acr-plugin/compare/maven-acr-plugin-1.0..
.m
aven-acr-plugin-1.1 - but this shows all changes. I'm not sure how to
limit
it to specific file.


Regards,
Plamen Totev

-
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


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




-
To unsubscribe, e-mail:

Re: Maven site edit next steps

[Plamen Totev]

Hi,


On 1/9/2018 3:25 AM, Hervé BOUTEMY wrote:
>
> I tried to integrate both [1], with GitWeb as "diff" and GitHub as "commits".
> But the GitHub comparison does not work well: then I put it only on HEAD.
>
> I don't know if this is due to my recent rework of tags for the repo, but
> GitHub does not recognise any tag on this maven-apache-parent repo. Perhaps
> there is a cache that will be reworked in a few days, since the rework
> happened also for maven-acr-plugin and the link works
>
> Any idea?


I wouldn't be surprised if there is a cache - the tags are not
supposed to change under normal circumstances. Anyway now everything
seems to work. Here are some examples:

* The commits between the latest release and HEAD (I believe
asf-LATEST points to wrong URL - HEAD...apache-18 instead of
apache-18...HEAD):
https://github.com/apache/maven-apache-parent/compare/apache-18...HEAD
* The commits between apache-18 and apache-17:
https://github.com/apache/maven-apache-parent/compare/apache-17...apache-18

I guess the tags are now updated so it should work for you as well.

Regards,
Plamen Totev

p.s. Hervé, excuse me for the spam. The first message was intended for
the group. I'm using a new mail client and I've just noticed that when
I hit reply the "To" field is set to the sender not the group. I hope
I'll get used to it quickly - don't want to spam you anymore :)

On Tue, Jan 9, 2018 at 3:25 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> thank you Plamen: useful answer, as usual
>
> I like both GitWeb and GitHub displays: both are useful, but for different
> purpose
>
> I tried to integrate both [1], with GitWeb as "diff" and GitHub as "commits".
> But the GitHub comparison does not work well: then I put it only on HEAD.
>
> I don't know if this is due to my recent rework of tags for the repo, but
> GitHub does not recognise any tag on this maven-apache-parent repo. Perhaps
> there is a cache that will be reworked in a few days, since the rework
> happened also for maven-acr-plugin and the link works
>
> Any idea?
>
> Regards,
>
> Hervé
>
> [1] http://maven.apache.org/pom-archives/asf-LATEST/
>
> Le dimanche 7 janvier 2018, 20:45:28 CET Plamen Totev a écrit :
>> Hi,
>>
>> On Fri, Jan 5, 2018 at 9:33 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
>> > - notice for parent poms: with Subversion, we had a cool feature which was
>> > the pom.xml diff from version to version published in the documentation
>> > page [1]. Does somebody have an idea on how we could do something
>> > equivalent with git?
>> Here are example links for Git Web (the software used by gitbox.apache.org):
>>
>> * To view maven-acr-plugin project's pom.xml file at specific tag
>> (maven-acr-plugin-1.1) -
>> https://gitbox.apache.org/repos/asf?p=maven-acr-plugin.git;a=blob;f=pom.xml;
>> hb=maven-acr-plugin-1.1 * To view the difference for pom.xml file between
>> maven-acr-plugin-1.1 and maven-acr-plugin-1.0 -
>> https://gitbox.apache.org/repos/asf?p=maven-acr-plugin.git;a=blobdiff;f=pom.
>> xml;hb=maven-acr-plugin-1.1;hpb=maven-acr-plugin-1.0
>>
>> For GitHub the links are:
>>
>> *
>> https://github.com/apache/maven-acr-plugin/blob/maven-acr-plugin-1.1/pom.xm
>> l *
>> https://github.com/apache/maven-acr-plugin/compare/maven-acr-plugin-1.0...m
>> aven-acr-plugin-1.1 - but this shows all changes. I'm not sure how to limit
>> it to specific file.
>>
>>
>> Regards,
>> Plamen Totev
>>
>> -
>> 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
>

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

Re: Maven site edit next steps

[Plamen Totev]

Hi,

On Fri, Jan 5, 2018 at 9:33 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:

> - notice for parent poms: with Subversion, we had a cool feature which was the
> pom.xml diff from version to version published in the documentation page [1].
> Does somebody have an idea on how we could do something equivalent with git?

Here are example links for Git Web (the software used by gitbox.apache.org):

* To view maven-acr-plugin project's pom.xml file at specific tag
(maven-acr-plugin-1.1) -
https://gitbox.apache.org/repos/asf?p=maven-acr-plugin.git;a=blob;f=pom.xml;hb=maven-acr-plugin-1.1
* To view the difference for pom.xml file between maven-acr-plugin-1.1
and maven-acr-plugin-1.0 -
https://gitbox.apache.org/repos/asf?p=maven-acr-plugin.git;a=blobdiff;f=pom.xml;hb=maven-acr-plugin-1.1;hpb=maven-acr-plugin-1.0

For GitHub the links are:

* https://github.com/apache/maven-acr-plugin/blob/maven-acr-plugin-1.1/pom.xml
* 
https://github.com/apache/maven-acr-plugin/compare/maven-acr-plugin-1.0...maven-acr-plugin-1.1
- but this shows all changes. I'm not sure how to limit it to specific
file.


Regards,
Plamen Totev

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

Re: [IMPORTANT] Re: Git migration next steps

[Plamen Totev]

Hi,



On Thu, Jan 4, 2018 at 8:42 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> on maven-fluido skin, most history is perfect now. There is only one tag
that
> has been done from a branch: maven-fluido-skin-1.3.1
> But the current Git history does not represent this branch as a branch
from
> master done from commit d57a437c384e3de4c816a69b471493192d82e95d "create a
> fluido 1.3.x branch" but as a dedicated completely unrelated/detached
branch
> that has equivalent commits to master
>
> It would be nice if we could fix this: I'm sure a few other locations
could
> benefit from such a branch improvement
>

This is easy to fix although maybe not that not that easy to automate.
You can create the branch from the tag:

$ git checkout -b 1.3.x maven-fluido-skin-1.3.1

Then you can just get the commits between the tip of the branch and
the first commit of the branch(the commit in SVN that creates the
branch) and rebase them on top of the commit from master we should
branch from. You already found the first commit of the branch -
d57a437c384e3de4c816a69b471493192d82e95d. I think the commit we should
branch from is the previous commit in SVN - [MSKINS-85] Unify
breadcrumb chevron of Fluido with other skins. That is
f6c6eec6e01b7dcc6e39fe87aef05845f626cce7 in master. So the rebase
command is:

$ git rebase --onto f6c6eec6e01b7dcc6e39fe87aef05845f626cce7
d57a437c384e3de4c816a69b471493192d82e95d 1.3.x

By default rebase will remove the empty commits ("create a  fluido
1.3.x branch" and "copy for tag") so the only thing left is to update
the tag(the HEAD is actually the 1.3.1 release):

$ git tag -f -a maven-fluido-skin-1.3.1

Regards,
Plamen Totev

p.s. Hervé, sorry looks like I've hit reply instead of reply all. This is
the second attempt to send it to the list as well.

On Jan 4, 2018 8:42 AM, "Hervé BOUTEMY" <herve.bout...@free.fr> wrote:

> shared components and skins done (only 4 shared components remains to do:
> maven-filtering, maven-osgi, maven-reporting-impl and maven-shared-jar,
> which
> require a little bit of investigation like many plugins
>
> Plamen, I have a new challenge for you :)
> on maven-fluido skin, most history is perfect now. There is only one tag
> that
> has been done from a branch: maven-fluido-skin-1.3.1
> But the current Git history does not represent this branch as a branch from
> master done from commit d57a437c384e3de4c816a69b471493192d82e95d "create a
> fluido 1.3.x branch" but as a dedicated completely unrelated/detached
> branch
> that has equivalent commits to master
>
> It would be nice if we could fix this: I'm sure a few other locations could
> benefit from such a branch improvement
>
> Thanks in advance for your light on this :)
>
> Regards,
>
> Hervé
>
> Le mercredi 3 janvier 2018, 00:51:19 CET Hervé BOUTEMY a écrit :
> > Great
> >
> > I pushed tags where the situation was clear.
> >
> > I chose not to push maven-compiler-plugin-2.0.1, since it causes more
> > trouble than this minor version (from 2006, between 2.0 and 2.0.2) is
> worth
> > Same for maven-shade-plugin-1.0
> >
> > I still need to work on maven-assembly-plugin, maven-dependency-plugin
> and
> > maven-site-plugin: this last one is tricky because we had parallel
> branches
> > for 2.x and 3.x...
> >
> > IMHO, the quality of the tags os now good enough: we know that absolute
> > reference is svn, but the git mirror has sufficient details
> >
> > This WE, I'll do the same work on shared components and skins.
> >
> >
> > thank you for your help
> >
> > Hervé
> >
> > Le mardi 2 janvier 2018, 14:32:00 CET Plamen Totev a écrit :
> > > Hi,
> > >
> > > > On Thu, Dec 28, 2017 at 10:43 AM, Hervé BOUTEMY <
> herve.bout...@free.fr>
> > > > wrote: thank you Plamen: this script is really awesome!
> > >
> > > You're welcome. I'm glad it helped.
> > >
> > > > And I just pushed the result on maven-acr-plugin: you can see the
> result
> > > > live. As you can see, the tags on GitBox [2] are updated but not the
> > > > tags
> > > > on GitHub [3] even if I tried to force to GitHub (and it looked ok)
> > > > I don't know if it's a major issue
> > >
> > > Would you check again. To me it looks like as if now the tags on
> > > GitHub are updated as well.
> > >
> > > > The rework of tags is ok for 420 tags on plugins, and fails for 31:
> > > > - 16 tags don't point to a release plugin commit [4]
> > >
> > > The script tries to find the "[maven-release-plugin] prepare release"
&g

Re: [IMPORTANT] Re: Git migration next steps

[Plamen Totev]

Hi,

> On Thu, Dec 28, 2017 at 10:43 AM, Hervé BOUTEMY <herve.bout...@free.fr> 
> wrote:
> thank you Plamen: this script is really awesome!

You're welcome. I'm glad it helped.

> And I just pushed the result on maven-acr-plugin: you can see the result live.
> As you can see, the tags on GitBox [2] are updated but not the tags on GitHub
> [3] even if I tried to force to GitHub (and it looked ok)
> I don't know if it's a major issue

Would you check again. To me it looks like as if now the tags on
GitHub are updated as well.

> The rework of tags is ok for 420 tags on plugins, and fails for 31:
> - 16 tags don't point to a release plugin commit [4]

The script tries to find the "[maven-release-plugin] prepare release"
commit reachable from the master branch and if it does not find it
then it says that the commit is not made with the release plugin.
Looks like there a couple of such cases (at least the commit message
is different). They are:

* maven-checkstyle-plugin-2.11 - the "copy for tag" commit is with
revision 1540890. The previous commit 1540889 is with message "foo"
(literally), but if you examine the content you'll see that this is
the commit that does the release. So I think it's safe to tag it - its
SHA in the split repository is
8f09be0a11e9761cceca127f4f8dcd439dcc561e[1].
* maven-dependency-plugin-2.0-alpha-2 - the "copy for tag" commit is
with revision 517496. The previous commit 517495 is with message
"rollback plexus-utils to 1.1 to avoid conflicts with m2.0.6", but
again if you examine the content you'll see that this is the commit
that does the release. Its SHA in the split repository is
9af772788381f5b79081a649748b2d8137782895[2].
* maven-help-plugin-2.0.1 - looks like the release is
2f95a7ecb720f95c1cbde1a52b3360964be29e72[3]. The commit message is
"[maven-release-plugin] prepare release maven-help-plugin-2.0" but if
you check the pom version you'll see it is 2.0.1
* maven-project-info-reports-plugin-mvn%20release%3Aprepare - Actually
there is a "prepare release"
commit(9de1aa37f0d38547aea80eac1abfe2078c2220c1[4]) but it is not
found by the script because of the escape characters in the tag name.
Actually I don't think this tag is needed as it seems to point to a
release attempt gone wrong.

Another possible cause is that there is "prepare release" commit but
it's not reachable from master. Looks like some of the plugins have
been released from branch and those commits are not part of the master
branch. Here is a list with such releases:

* maven-assembly-plugin-2.2-beta-4 is released from branch
maven-assembly-plugin-2.2-beta-4
* maven-assembly-plugin-2.6 is released from branch maven-assembly-plugin-2.x
* maven-compiler-plugin-2.0.1 is released from branch
maven-compiler-plugin-2.0.x
* maven-site-plugin-2.4 is released from maven-site-plugin-2.x
* maven-site-plugin-3.0-beta-1, maven-site-plugin-3.0-beta-2,
maven-site-plugin-3.0-beta-3 are released from maven-site-plugin-3.x

The branches are not preserved in the split repositories(but they do
exist in maven-plugins). I guess we should migrate them as well or I'm
wrong? Do you think it will be an issue to have branches after the
migration that are not merged into master? Migrating the branches into
the split repositories should not be complicated (I think) but haven't
tried yet. I may try to migrate maven-site-plugin-3.x for example to
see how it is in reality.

Also it appears that some of the plugins were part of "sandbox" and
this part of their history is not preserved after the split (I'm not
sure how much of it is part of maven-plugins. Keeping this part of the
history may prove to be more difficult.

* maven-shade-plugin-1.0-alpha-13, maven-shade-plugin-1.0-alpha-14 and
maven-shade-plugin-1.0-alpha-15 were released when the Shade plugin
was in the 
sandbox(https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-shade-plugin).

I have no idea about the cause for
maven-dependency-plugin-2.0-alpha-1-RC2 and
maven-site-plugin-pre-compat-with-doxia-1.0-alpha-7 tags.

> - 15 tags have an issue I don't really understand yet [5]

I haven't looked at them yet, but in general the error means that a
"prepare release" commit reachable from master is found but the
content of the files (the SHA of the root tree) does not match the
tagged ones. I suspect that the cause may be that there are a multiple
attempts on release and the last one does not match the tagged(for
example the first one is tagged).

Regards,
Plamen Totev

[1] 
https://github.com/apache/maven-checkstyle-plugin/commit/8f09be0a11e9761cceca127f4f8dcd439dcc561e
[2] 
https://github.com/apache/maven-dependency-plugin/commit/9af772788381f5b79081a649748b2d8137782895
[3] 
https://github.com/apache/maven-help-plugin/commit/2f95a7ecb720f95c1cbde1a52b3360964be29e72
[4] 
https://github.com/apache/maven-project-info-reports-plugin/commit/9de1aa37f0d38547aea80eac1abfe2078c2220c1

Re: [IMPORTANT] Re: Git migration next steps

[Plamen Totev]

Hi,

I've created the script. Not sure how to share it with the list so
I've created a gist -
https://gist.github.com/plamentotev/b835dd62c74a3a5becd4c317b97403a4

It will migrate the tags for all repositories in plugins/maven-* Also
it checks for the 'git-svn' string in the commit message so it will
not migrate tags created after the git migration.
And I have commented the `git tag` command so by default it will be
run in "dry mode" that will print all errors found without changing
the repositories.

Speaking of errors - there are about 30 tags that could not be
automatically migrated. They are actually two group of errors:

* the "prepare release" commit does not have the same files as the tag
- meaning that most likely the tag in SVN is not just a copy of the
"prepare release" commit and contains some changes made after that
* there is no "prepare release" commit reachable from master. That
could mean that the tag is not created by the release plugin and
sometimes that is the case, but it looks like the majority of the
cases are because the release is created from branch and not from
trunk. And while we're on the topic - looks like the branches are not
migrated into the maven-plugins repository.

Also as the script modifies the tag I fell obligated to mention the
usual warning when changing tags -
https://git-scm.com/docs/git-tag#_on_backdating_tags

Regards,
Plamen Totev

On Thu, Dec 28, 2017 at 10:43 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> Hi Plamen,
>
> Thank you for your help
>
> Yes, I looked more in depth to maven-plugins svn2git mirror and the split
> result (got from the split script): the issue with tags is already there
>
> I like the idea of recreating tags from "[maven-release-plugin] prepare
> release " commit, ignoring the "[maven-release-plugin] copy
> for tag " commit that don't change anything in code
>
> If you can prepare a script to create the tags with this convention, it would
> really be useful (don't forget that sometimes there are multiple tries at one
> release, then the useful tag is the last one in time)
>
> Regards,
>
> Hervé
>
> Le lundi 25 décembre 2017, 09:58:36 CET Plamen Totev a écrit :
>> Hi,
>>
>> What I can see is that the tags actually introduce new branches that
>> contain commits with the same content as the one in the master (trunk)
>> branch. But this is not caused by the script that splits of the
>> repository - the problem exists in the maven-plugins Git repository as
>> well. Maybe it's not quite visible because there are a lot of commits,
>> but it's there.
>>
>> How can it be fixed? I think it would be easier to fix the individual
>> plugin repositories (after the split) as they are smaller and easier
>> to work with. The plan is simple - as the branches created by the tags
>> does not contain new commits(with a single exception but I'll explain
>> that in a minute) and all of them are present in the master branch  we
>> could just change the tag to point to the same commits but in the
>> master branch. That will cause all extra commits and branches to be
>> garbage collected as they are accessible only from the tags. For our
>> purposes commits are equal if they point to the same root tree (the
>> same files with the same content). But unfortunately there is a catch.
>> What I said about the branches created by the tags is not strictly
>> true - they do have some extra commits. When you release in SVN you
>> have the following sequence of commits:
>>
>> * [maven-release-plugin] copy for tag maven-war-plugin-3.2.0 (this is
>> the tagged commit)
>> * [maven-release-plugin] prepare release maven-war-plugin-3.2.0
>>
>> After the migration to Git the master (trunk) branch contain only the
>> 'prepare release' commit but not the 'copy for tag' commit. So if we
>> apply my plan then the 'copy for tag' commit will be lost. It's just a
>> copy (no changes, it contains the same files as the previous commit)
>> so I don't think it's a problem but would be nice if somebody
>> confirms.
>>
>> So the proposed plan have the following caveats:
>>
>> * the 'copy for tag' commits will be lost. No changes will be lost as
>> those are only copy commits
>> * the tags will point to the previous 'prepare release' commits
>> * the tags SHA will be changed because they point to a different commit
>>
>> If that is OK I can write a script that will apply those changes.
>>
>> What causes the branches and all those duplicating commits? Well the
>> master branch tracks
>> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins
>> but the tags for the pl

Re: maven-archiver build on Jenkins - Test Failures

[Plamen Totev]

And if this could help (I know it's obvious but may safe time) it
looks the reason for the failing tests is the same. The following code
fails with assertion error:

final Manifest manifest = getJarFileManifest( jarFile );
String classPath = manifest.getMainAttributes().getValue(
Attributes.Name.CLASS_PATH );
assertNotNull( classPath );

The NullPointerExceptions from the rest of the tests are coming from
the same expression (`manifest.getMainAttributes().getValue(
"Class-Path" ).getBytes()`).

On Wed, Dec 27, 2017 at 9:39 AM, Plamen Totev <plamen.iv.to...@gmail.com> wrote:
> Hi,
>
> On Tue, Dec 26, 2017 at 9:01 PM, Karl Heinz Marbaise <khmarba...@gmx.de> 
> wrote:
>
>> Is someone out there who can check the current state of maven-archiver git
>> repo on Windows and can reproduce the issue ?
>
> I ran the build a couple of times(just in case) on Windows 10, Maven
> 3.5.2, JDK 9.0.1 and everything is ok. And it looks like the build is
> failing on Linux JDK 9 and Windows JDK 8 as well, so if there is a bug
> (and not a problem with the build) then it is probably not a Windows
> or JDK 9 related.
>
> Regards,
> Plamen Totev

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

Re: maven-archiver build on Jenkins - Test Failures

[Plamen Totev]

Hi,

On Tue, Dec 26, 2017 at 9:01 PM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:

> Is someone out there who can check the current state of maven-archiver git
> repo on Windows and can reproduce the issue ?

I ran the build a couple of times(just in case) on Windows 10, Maven
3.5.2, JDK 9.0.1 and everything is ok. And it looks like the build is
failing on Linux JDK 9 and Windows JDK 8 as well, so if there is a bug
(and not a problem with the build) then it is probably not a Windows
or JDK 9 related.

Regards,
Plamen Totev

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

Re: [IMPORTANT] Re: Git migration next steps

[Plamen Totev]

p.s. I just saw a mistake in my previous message. What I wrote is:

So for maven-war-plugins you have two commits in the maven-plugins Git
repository - one for
https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-war-plugin
and one for https://svn.apache.org/repos/asf/maven/components/trunk/
no matter that actually those commits are the same - same date,
author, message, files, etc.

but what I meant is:

So for maven-war-plugins you have two commits in the maven-plugins Git
repository - one for
https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-war-plugin
and one for 
https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/
no matter that actually those commits are the same - same date,
author, message, files, etc.

I've just missed maven-plugins/ from the last URL

On Mon, Dec 25, 2017 at 10:58 AM, Plamen Totev
<plamen.iv.to...@gmail.com> wrote:
> Hi,
>
> What I can see is that the tags actually introduce new branches that
> contain commits with the same content as the one in the master (trunk)
> branch. But this is not caused by the script that splits of the
> repository - the problem exists in the maven-plugins Git repository as
> well. Maybe it's not quite visible because there are a lot of commits,
> but it's there.
>
> How can it be fixed? I think it would be easier to fix the individual
> plugin repositories (after the split) as they are smaller and easier
> to work with. The plan is simple - as the branches created by the tags
> does not contain new commits(with a single exception but I'll explain
> that in a minute) and all of them are present in the master branch  we
> could just change the tag to point to the same commits but in the
> master branch. That will cause all extra commits and branches to be
> garbage collected as they are accessible only from the tags. For our
> purposes commits are equal if they point to the same root tree (the
> same files with the same content). But unfortunately there is a catch.
> What I said about the branches created by the tags is not strictly
> true - they do have some extra commits. When you release in SVN you
> have the following sequence of commits:
>
> * [maven-release-plugin] copy for tag maven-war-plugin-3.2.0 (this is
> the tagged commit)
> * [maven-release-plugin] prepare release maven-war-plugin-3.2.0
>
> After the migration to Git the master (trunk) branch contain only the
> 'prepare release' commit but not the 'copy for tag' commit. So if we
> apply my plan then the 'copy for tag' commit will be lost. It's just a
> copy (no changes, it contains the same files as the previous commit)
> so I don't think it's a problem but would be nice if somebody
> confirms.
>
> So the proposed plan have the following caveats:
>
> * the 'copy for tag' commits will be lost. No changes will be lost as
> those are only copy commits
> * the tags will point to the previous 'prepare release' commits
> * the tags SHA will be changed because they point to a different commit
>
> If that is OK I can write a script that will apply those changes.
>
> What causes the branches and all those duplicating commits? Well the
> master branch tracks
> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins
> but the tags for the plugins are actually tracking the plugin
> directory (for example:
> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-war-plugin).
> So for maven-war-plugins you have two commits in the maven-plugins Git
> repository - one for
> https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-war-plugin
> and one for https://svn.apache.org/repos/asf/maven/components/trunk/
> no matter that actually those commits are the same - same date,
> author, message, files, etc.
>
> Regards,
> Plamen Totev
>
> On Sun, Dec 24, 2017 at 11:54 AM,  <herve.bout...@free.fr> wrote:
>> I'd suggest to try the process to a personal personal repo on GitHub to see 
>> if you're able to get a better result before involving manual work from 
>> INFRA (on more than 60 repos...)
>>
>> (it's sad to see nobody try to explain what's happenning or improve the 
>> documented commands, just get to a conclusion: re-do everything and pray)
>>
>> Regards,
>>
>> Hervé
>>
>> - Mail original -
>> De: "Karl Heinz Marbaise" <khmarba...@gmx.de>
>> À: "Maven Developers List" <dev@maven.apache.org>, "Robert Scholte" 
>> <rfscho...@apache.org>
>> Envoyé: Dimanche 24 Décembre 2017 10:47:43
>> Objet: Re: [IMPORTANT] Re: Git migration next steps
>>
>> Hi,
>>
>> On 24/12/17 10:40, Robert Scholte wrote:
>>> How about a h

Re: [IMPORTANT] Re: Git migration next steps

[Plamen Totev]

Hi,

What I can see is that the tags actually introduce new branches that
contain commits with the same content as the one in the master (trunk)
branch. But this is not caused by the script that splits of the
repository - the problem exists in the maven-plugins Git repository as
well. Maybe it's not quite visible because there are a lot of commits,
but it's there.

How can it be fixed? I think it would be easier to fix the individual
plugin repositories (after the split) as they are smaller and easier
to work with. The plan is simple - as the branches created by the tags
does not contain new commits(with a single exception but I'll explain
that in a minute) and all of them are present in the master branch  we
could just change the tag to point to the same commits but in the
master branch. That will cause all extra commits and branches to be
garbage collected as they are accessible only from the tags. For our
purposes commits are equal if they point to the same root tree (the
same files with the same content). But unfortunately there is a catch.
What I said about the branches created by the tags is not strictly
true - they do have some extra commits. When you release in SVN you
have the following sequence of commits:

* [maven-release-plugin] copy for tag maven-war-plugin-3.2.0 (this is
the tagged commit)
* [maven-release-plugin] prepare release maven-war-plugin-3.2.0

After the migration to Git the master (trunk) branch contain only the
'prepare release' commit but not the 'copy for tag' commit. So if we
apply my plan then the 'copy for tag' commit will be lost. It's just a
copy (no changes, it contains the same files as the previous commit)
so I don't think it's a problem but would be nice if somebody
confirms.

So the proposed plan have the following caveats:

* the 'copy for tag' commits will be lost. No changes will be lost as
those are only copy commits
* the tags will point to the previous 'prepare release' commits
* the tags SHA will be changed because they point to a different commit

If that is OK I can write a script that will apply those changes.

What causes the branches and all those duplicating commits? Well the
master branch tracks
https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins
but the tags for the plugins are actually tracking the plugin
directory (for example:
https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-war-plugin).
So for maven-war-plugins you have two commits in the maven-plugins Git
repository - one for
https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-war-plugin
and one for https://svn.apache.org/repos/asf/maven/components/trunk/
no matter that actually those commits are the same - same date,
author, message, files, etc.

Regards,
Plamen Totev

On Sun, Dec 24, 2017 at 11:54 AM,  <herve.bout...@free.fr> wrote:
> I'd suggest to try the process to a personal personal repo on GitHub to see 
> if you're able to get a better result before involving manual work from INFRA 
> (on more than 60 repos...)
>
> (it's sad to see nobody try to explain what's happenning or improve the 
> documented commands, just get to a conclusion: re-do everything and pray)
>
> Regards,
>
> Hervé
>
> - Mail original -
> De: "Karl Heinz Marbaise" <khmarba...@gmx.de>
> À: "Maven Developers List" <dev@maven.apache.org>, "Robert Scholte" 
> <rfscho...@apache.org>
> Envoyé: Dimanche 24 Décembre 2017 10:47:43
> Objet: Re: [IMPORTANT] Re: Git migration next steps
>
> Hi,
>
> On 24/12/17 10:40, Robert Scholte wrote:
>> How about a hard reset or dropping the repo and doing it all over again?
>
> If I correctly seen that ..there had no commit yet on the new git repos..
>
> So I think it would be the easiest way to do as Robert suggest ...to
> redo migration for those repos..
>
> Kind regards
> Karl Heinz
>>
>> On Wed, 20 Dec 2017 10:42:36 +0100, Hervé BOUTEMY
>> <herve.bout...@free.fr> wrote:
>>
>>> INFRA-15679 fixed by infra team
>>> then I re-run migrate-plugins.sh script to split the svn2git mirror to
>>> per-
>>> plugin git repo
>>> and I pushed "master2" branches for m-javadoc-p, m-site-p and m-pdf-p,
>>> which
>>> were the 3 plugins which suffered from missing commits
>>>
>>> on m-site-p and m-pdf-p, I'll cherry pick the unique commit that was
>>> missed:
>>> not a big deal
>>>
>>> on m-javadoc-p, the situation is more coplex, since there was a release
>>>
>>> I also noticed that I forgot to push tags when importing: I started to
>>> do "git
>>> push --tags", but the result does not look as I expected: it creates a
>>> lot of
>>> parallel branches
>>>
>>&

Re: main-class + module-version

[Plamen Totev]

Hi,

Actually that might just work. Good idea. I'll take a look at it.

Thanks,
Plamen Totev

On Wed, Dec 20, 2017 at 9:53 PM, Robert Scholte <rfscho...@apache.org> wrote:
> On Wed, 20 Dec 2017 07:40:24 +0100, Plamen Totev <plamen.iv.to...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I've started working on implementing support for modular JARs in
>> Plexus Archiver but as I research the matter I found that they are
>> more complex than I expected. I've updated the GitHub issue[1] with
>> the details but I'll post the findings here as well. The modular JAR
>> files contain not only version and main class but also:
>>
>> * List of the packages contained - usually populated by the compiler,
>> but there are some caveats here. The most obvious one is that for jars
>> created by the Shade Plugin this attribute will almost certainly be
>> incorrect - the plugin will most likely introduce additional packages
>> and the list produced by the compiler will be out of date. The other
>> caveat are the resources - they could be located in packages and
>> encapsulated the same way as the classes. The jar tools records not
>> only the class packages but the resource ones too. Packaging resources
>> together with the classes may result in incorrect module descriptor if
>> this attribute is not updated.
>>
>> * The module main class - passed as argument to the jar tool and it
>> seems that it cannot be set using the compiler.
>>
>> * The module version - passed as argument to the jar tool. Could be
>> set using the compiler(again passed as argument) as well.
>>
>> * Hashes - calculates the hashes of given external modules that depend
>> on this one. During runtime java checks the recorded hashes against
>> the resolved module and and if don't match it will fail. The primary
>> use case is a module A that exports packages to B and C. An easy way
>> to break the encapsulation of A is to create module named B. To
>> prevent that you can record the hash of B and C inside A. Then A will
>> export the packages only to the intended modules. It is used by the
>> OpenJDK but could be useful for platforms and frameworks as well.
>>
>> * Module resolution - marks the module to not be resolved by default or
>> marks it as deprecated or incubating so at run time a warning is
>> displayed if it is resolved. I don't think you can set it using the
>> JDK 9 jar tool but it's present in the code. Maybe it will be
>> implemented in future version of the jar tool.
>>
>> To me it looks like the packaging of modular JAR file is more complex
>> than just packing module-info.class file and the jar tool is no longer
>> just a ZIP program. Something similar is stated in the tool
>> documentation[2]:
>>
>>> The jar command is a general-purpose archiving and compression tool,
>>> based on the ZIP and ZLIB compression formats.
>>> Initially, the jar command was designed to package Java applets
>>> or applications; however, beginning with JDK 9, users can use the
>>> jar command to create modular JARs.
>>> For transportation and deployment, it’s usually more convenient to
>>> package modules as modular JARs.
>>
>>
>> While not at all that complex from technical point of view, I don't
>> think it is worth implementing, and whats more maintaining, all this
>> functionality. Probably it would be better if the plugins that produce
>> JAR files use the jar tool, the same way the compiler plugin does not
>> compile by itself but uses the Java compiler.
>>
>> What do you think?
>
>
> Based on this message it seems worth implementing a JarToolArchiver, using
> the jar tool via the ToolProvider[1]
> I hope it can still be a org.codehaus.plexus.archiver.Archiver, otherwise
> I'll contact the openjdk team about the details of the specifications. I
> don't think we need them all, good to know the reason for the extra files.
>
> thanks so far,
> Robert
>
>
> [1]
> https://docs.oracle.com/javase/9/docs/api/jdk.jartool-summary.html#module.description
>
>>
>>
>> [1]
>> https://github.com/codehaus-plexus/plexus-archiver/issues/69#issuecomment-349095101
>> [2] https://docs.oracle.com/javase/9/tools/jar.htm
>>
>> -
>> 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
>

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

Re: main-class + module-version

[Plamen Totev]

Hi,

I've started working on implementing support for modular JARs in
Plexus Archiver but as I research the matter I found that they are
more complex than I expected. I've updated the GitHub issue[1] with
the details but I'll post the findings here as well. The modular JAR
files contain not only version and main class but also:

* List of the packages contained - usually populated by the compiler,
but there are some caveats here. The most obvious one is that for jars
created by the Shade Plugin this attribute will almost certainly be
incorrect - the plugin will most likely introduce additional packages
and the list produced by the compiler will be out of date. The other
caveat are the resources - they could be located in packages and
encapsulated the same way as the classes. The jar tools records not
only the class packages but the resource ones too. Packaging resources
together with the classes may result in incorrect module descriptor if
this attribute is not updated.

* The module main class - passed as argument to the jar tool and it
seems that it cannot be set using the compiler.

* The module version - passed as argument to the jar tool. Could be
set using the compiler(again passed as argument) as well.

* Hashes - calculates the hashes of given external modules that depend
on this one. During runtime java checks the recorded hashes against
the resolved module and and if don't match it will fail. The primary
use case is a module A that exports packages to B and C. An easy way
to break the encapsulation of A is to create module named B. To
prevent that you can record the hash of B and C inside A. Then A will
export the packages only to the intended modules. It is used by the
OpenJDK but could be useful for platforms and frameworks as well.

* Module resolution - marks the module to not be resolved by default or
marks it as deprecated or incubating so at run time a warning is
displayed if it is resolved. I don't think you can set it using the
JDK 9 jar tool but it's present in the code. Maybe it will be
implemented in future version of the jar tool.

To me it looks like the packaging of modular JAR file is more complex
than just packing module-info.class file and the jar tool is no longer
just a ZIP program. Something similar is stated in the tool
documentation[2]:

> The jar command is a general-purpose archiving and compression tool,
> based on the ZIP and ZLIB compression formats.
> Initially, the jar command was designed to package Java applets
> or applications; however, beginning with JDK 9, users can use the
> jar command to create modular JARs.
> For transportation and deployment, it’s usually more convenient to
> package modules as modular JARs.

While not at all that complex from technical point of view, I don't
think it is worth implementing, and whats more maintaining, all this
functionality. Probably it would be better if the plugins that produce
JAR files use the jar tool, the same way the compiler plugin does not
compile by itself but uses the Java compiler.

What do you think?


[1] 
https://github.com/codehaus-plexus/plexus-archiver/issues/69#issuecomment-349095101
[2] https://docs.oracle.com/javase/9/tools/jar.htm

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

Re: main-class + module-version

[Plamen Totev]

Hi,

I've just implemented support for adding module version and main
class. There is pull request[1] and comments and suggestions are more
than welcome. The following excerpt from the test showcase how you can
add module version and main class to a modular JAR fie:

JarArchiver archiver = new JarArchiver();
archiver.setDestFile( jarFile );
archiver.addDirectory( new File( "src/test/resources/java-module" ) );

ModuleConfiguration moduleConfiguration = new ModuleConfiguration();
moduleConfiguration.setVersion( "1.0.0" );
moduleConfiguration.setMainClass( "com.example.app.Main" );
archiver.setModuleConfiguration( moduleConfiguration );

archiver.createArchive();

Regards,
Plamen Totev

[1] https://github.com/codehaus-plexus/plexus-archiver/pull/75

On Wed, Sep 6, 2017 at 10:03 PM, Plamen Totev <plamen.iv.to...@gmail.com> wrote:
> Hi,
>
> I've started working on this one. Unfortunately I don't have as much
> free time as I expected so the progress is a bit slow. With the
> release date of Java 9 approaching I hope this does not block any
> other release.
>
> I've just pushed my implementation [1]. It's not fully ready yet as
> there are no tests and Java Docs. The commit messages should be more
> detailed as well. But all changes to the API and the work on
> implementing the functionality are done so if you want you can take a
> look. Any comments and suggestions are welcome. I'll continue with the
> tests next week.
>
> Regards,
> Plamen Totev
>
>
> [1] 
> https://github.com/codehaus-plexus/plexus-archiver/compare/master...plamentotev:module-version-and-main-class
>
> On Wed, Aug 30, 2017 at 8:32 AM, Plamen Totev <plamen.iv.to...@gmail.com> 
> wrote:
>> Hi Robert,
>>
>>>
>>> I've started a bit with it, but no success yet:
>>> https://mail.ow2.org/wws/arc/asm/2017-08/msg4.html
>>>
>>> Even after the suggestions from Remi no success yet.
>>> I was hoping for a fast fix, but it'll take more time and other things are
>>> waiting as well.
>>> Would be great if you can pick it up from here.
>>
>> Yes, I will. Thanks for the starting point. I took a look at the asm
>> API, the class file format and the jar tool implementation so I should
>> be able to continue from here.
>>
>> Regards,
>> Plamen Totev

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

Re: main-class + module-version

[Plamen Totev]

Hi,

I've started working on this one. Unfortunately I don't have as much
free time as I expected so the progress is a bit slow. With the
release date of Java 9 approaching I hope this does not block any
other release.

I've just pushed my implementation [1]. It's not fully ready yet as
there are no tests and Java Docs. The commit messages should be more
detailed as well. But all changes to the API and the work on
implementing the functionality are done so if you want you can take a
look. Any comments and suggestions are welcome. I'll continue with the
tests next week.

Regards,
Plamen Totev


[1] 
https://github.com/codehaus-plexus/plexus-archiver/compare/master...plamentotev:module-version-and-main-class

On Wed, Aug 30, 2017 at 8:32 AM, Plamen Totev <plamen.iv.to...@gmail.com> wrote:
> Hi Robert,
>
>>
>> I've started a bit with it, but no success yet:
>> https://mail.ow2.org/wws/arc/asm/2017-08/msg4.html
>>
>> Even after the suggestions from Remi no success yet.
>> I was hoping for a fast fix, but it'll take more time and other things are
>> waiting as well.
>> Would be great if you can pick it up from here.
>
> Yes, I will. Thanks for the starting point. I took a look at the asm
> API, the class file format and the jar tool implementation so I should
> be able to continue from here.
>
> Regards,
> Plamen Totev

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

Re: main-class + module-version

[Plamen Totev]

Hi Robert,

>
> I've started a bit with it, but no success yet:
> https://mail.ow2.org/wws/arc/asm/2017-08/msg4.html
>
> Even after the suggestions from Remi no success yet.
> I was hoping for a fast fix, but it'll take more time and other things are
> waiting as well.
> Would be great if you can pick it up from here.

Yes, I will. Thanks for the starting point. I took a look at the asm
API, the class file format and the jar tool implementation so I should
be able to continue from here.

Regards,
Plamen Totev

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

Re: main-class + module-version

[Plamen Totev]

Hi Robert,

Thank you for you comments.

>> Also I took a look at the changes in the JDK jar tool and I notice a
>> couple of things that it does:
>>
>> 1. The structure of the jar produced is such that the module info
>> entries are placed after the manifest and before the rest of the
>> files. Plexus Archiver does not handle  the module info entries
>> differently and they are placed in random order among the rest of the
>> files.
>
>
> IIRC Plexus Archiver is already capable to put the manifest file up front.
> The same should be possible with the module descriptor.

I double checked the changes in the Jar File Specifications [1] and
there are no requirements specifying where the module-info.class entry
should be located in regard to the rest of the entries(I mean
physically in the file). So I consider this behavior implementation
specific.

> I think we need to focus on version and mainClass first, that's probably the
> first things users will ask and which is really visible to them. If the
> extra checks are not required I consider them as nice to have checks and
> pick them up later.

Makes sense. I created issues for them as well so we don't forget them.[2][3][4]

Regarding the implementation. Unfortunately as you mention it will
require adjusting the byte code of the module-info.class. And I don't
have knowledge in the matter so I'll need help with that. Also I was
thinking that maybe such functionality(adding/replacing  information
to the ModuleDescriptor) is good fit for the newly introduced
plexus-languages project?

Regards,
Plamen Totev

[1] http://cr.openjdk.java.net/~mr/jigsaw/spec/jar.html
[2] https://github.com/codehaus-plexus/plexus-archiver/issues/67
[3] https://github.com/codehaus-plexus/plexus-archiver/issues/68
[4] https://github.com/codehaus-plexus/plexus-archiver/issues/69

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

Re: main-class + module-version

[Plamen Totev]

Hi,

On Fri, Aug 25, 2017 at 6:57 PM, Robert Scholte <rfscho...@apache.org> wrote:
> I'm having a look at the JarArchiver of the plexus-archiver project as used
> by maven-jar-plugin.
> This archiver does some MANIFEST and index stuff already, so it kind of
> makes sense to add the module-descriptor logic here as well.

I think it is a good idea to make Plexus Archiver module aware. I can
help you with it if you want.

Also I took a look at the changes in the JDK jar tool and I notice a
couple of things that it does:

1. The structure of the jar produced is such that the module info
entries are placed after the manifest and before the rest of the
files. Plexus Archiver does not handle  the module info entries
differently and they are placed in random order among the rest of the
files.
2. It adds/replaces some additional information to the module
description such as the list of packages it contains, the hashes of
the modules, module version, main class.
3. There is verification that the module descriptor is consistent -
exported/opened/provided  packages/classes are actually presented in
the jar file.

I have to double check which of those are part of the specification
and which are OpenJdk specific. In any case it sounds like a good idea
to have some verification (3.) and to update the packages field with
the packages that are actually packaged. The module hashes seem to be
OpenJdk specific but they do sound like a nice feature. Maybe we
should do some(or all) of the above thing as well, what do you think?

The points above convince we even more that the Plexus Archiver should
be module aware and the component to verify/modify the module
descriptors.

BTW what do you think - should we have a new class ModuleJarArchiver
that extends JarArchiver or just to modify JarArchiver. There is no
new packaging type and from this POV it does sounds logical to just
modify the JarArchiver. But on other hand it is extended by
WarArchiver & co so they'll become module aware as well. Not
completely sure if that is ok. I guess they should be ok as they do
not contain any code(modules or not) in their root folder, right? Or I
am wrong?

Regards,
Plamen Totev

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

Re: main-class + module-version

[Plamen Totev]

On Tue, Aug 22, 2017 at 11:03 PM, Robert Scholte  wrote:
>
>
> The maven-shade-plugin has the ability to re-package a jar and manipulate any 
> type of file, including class files. The best example is relocation, where 
> you give a set of classes a different package to prevent potential class 
> collisions when the original dependency (probably with other version) is 
> added again.
> So this is a good match for the module-info.class adjustments.
>

Thank you for the detailed explanation. Initially I thought that if
this is not part of the jar plugin then the transformation should
happen before its execution(similar to the MANFEST.MF). Now on second
thought it also sounds logical to be done after. But still - isn't the
shade plugin supposed to be used for "uber jars" (at least its primary
purpose)? Correct me if I'm wrong, but its only target will create a
"uber jar". What if I want to set the module version but without
changing the rest of the jar? A configuration or new target will solve
this issue, but as a user of the plugin I think it would change its
purpose. And there is nothing wrong with that of course .

Also another important question for me. Do you think that other types
of packaging will benefit from setting the module version as well? I
mean not only now but in future as well. Some of the EE packaging
types for example.

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

Re: main-class + module-version

[Plamen Totev]

Hi,

I've experimented with Maven and Java 9 the last weekend and actually one
of the things I noticed is that currently I could not set the module
version.

I do agree that the packaging should be stupid action and the module-info
transformation should happen before that. But I'm not sure why the Maven
Shade plug-in is the place to do that. Probably I'm missing something,
would you explain a bit?

> Or should these extra (basic?) features require an extra setup of a
maven-plugin so all transformations are done by one plugin only.

My thoughts exactly. While it makes sense to have separate plugin for that
(maybe in the future the module-info.class will contain more information?),
I'm not sure it's worth to have separate plugin just for that. And if we
don't have separate plugin then I think the Jar plugin is the better place
because:
 1. this way it's consistent with the JDK tools
 2. up until Java 9 the usual place to put meta-information about the
package was to place in in the META-INF directory and package it. Of course
the processing

An interesting question (no matter which plugin does the transformation) is
that if the module-version should be added by default? I feel a bit
uncomfortable about the idea to enable it by default but on other hand
the module-info is a new class so it's unlikely to break anything and it
may prove tiresome to have to set the version explicitly. I mean why would
you want not to have the version set? I personally think that the majority
of the projects would like to have the version set.

Regards,
Plamen Totev

On Tue, Aug 22, 2017 at 8:17 PM, Robert Scholte <rfscho...@apache.org>
wrote:

> Hi,
>
> The JDK 9 jar packager comes with 2 extra options: main-class and
> module-version.
> The first one is used in case of an executable modular jar, the latter is
> just for display/analysis to show which version of a specific module is
> used.
> To support these 2 values, the module-info.class must be adjusted (yes,
> the bytecode!).
>
> It is not that hard to support this as well with a little help from ASM,
> but the question is: which plugin should do this: maven-jar-plugin or
> maven-shade-plugin?
> If you consider this kind of information to be part of the packaging
> process, maven-jar-plugin seems to be the best fit.
> However, if you consider this as a resource transformation, then
> maven-shade-plugin seems better.
>
> Personally I think packaging should be quite a stupid action: making a jar
> from a set of files. And it should be very reliable, since it is part of
> the lifecycle of the most used packaging type. Of course you can control
> this when exposed as parameters...
>
> Or should these extra (basic?) features require an extra setup of a
> maven-plugin so all transformations are done by one plugin only.
>
> WDYT?
> Robert
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: JDK9: Failed to parse module-info.java

[Plamen Totev]

Hi Robert,

Plexus Languages looks very promising and really needed component. May I
ask you something to clarify if I understand correctly it's purpose. The
intention is Plexus Languages to contain abstractions that represent the
code that is going to be build and not the JDK/JRE used to run Maven, right?

Regards,
Plamen Totev


On Sun, Aug 13, 2017 at 12:12 AM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:

> Hi Robert,
>
> I've made a separate issue MCOMPILER-304 to introduce plexus-language
> component.
>
> Kind regards
> Karl Heinz Marbaise
>
> On 12/08/17 19:23, Robert Scholte wrote:
>
>> Hi,
>>
>> short answer: to be able to compile Java 9 projects, you must use the JRE
>> from Maven (i.e. JAVA_HOME must point to JDK 9).
>>
>> The long story: asm-6.0_ALPHA is based on an old format of the
>> module-info file. Only a few weeks ago asm-6.0_BETA was released. There was
>> over a year between these 2 versions and I think is was relatively soon
>> after ALPHA that the format was changed.
>> The first solution I had implemented was using QDox during also during
>> test to read the module-info.java, which is not correct. Test should be
>> using the compiled version, i.e. module-info.class.
>> So I implemented a reflection-based implementation and replaced it for
>> QDox. This implementation uses reflection to access the module-descriptor.
>> But this means that Maven must be running with Java 9. Toolchain doesn't
>> help here.
>>
>> Right now I have the code ready to replace this. I also have started a
>> new project called plexus-languages[1], which has plexus-java. This
>> contains JRE/JDK related code which is used my multiple plugins / libraries.
>> Most important: this code is NOT related to Maven!
>>
>> One of the most important features: based on a JavaModuleDescriptor and a
>> set of jars + output directories and can make an accurate separation for
>> modulepath and classpath. Any feedback is appreciated.
>>
>> thanks,
>> Robert
>>
>> [1] https://github.com/codehaus-plexus/plexus-languages
>>
>>
>> On Sat, 12 Aug 2017 17:44:03 +0200, Karl Heinz Marbaise <
>> khmarba...@gmx.de> wrote:
>>
>> Hi,
>>>
>>> currently I'm facing the following issue with JDK9+181: (using
>>> maven-compiler-plugin:3.6.2):
>>>
>>> [DEBUG] CompilerReuseStrategy: reuseCreated
>>> [DEBUG] useIncrementalCompilation enabled
>>> [ERROR] Failed to parse module-info:
>>> [ERROR] With reflect: null
>>> [ERROR] With asm: null
>>>
>>> [ERROR] Failed to execute goal org.apache.maven.plugins:maven
>>> -compiler-plugin:3.6.2:testCompile (default-testCompile) on project
>>> devday-workshop-service: Execution default-testCompile of goal
>>> org.apache.maven.plugins:maven-compiler-plugin:3.6.2:testCompile
>>> failed: Failed to parse module-info -> [Help 1]
>>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
>>> execute goal org.apache.maven.plugins:maven
>>> -compiler-plugin:3.6.2:testCompile (default-testCompile) on project
>>> devday-workshop-service: Execution default-testCompile of goal
>>> org.apache.maven.plugins:maven-compiler-plugin:3.6.2:testCompile
>>> failed: Failed to parse module-info
>>> at 
>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
>>>
>>> at 
>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
>>>
>>> at 
>>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
>>>
>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.b
>>> uildProject(LifecycleModuleBuilder.java:117)
>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.b
>>> uildProject(LifecycleModuleBuilder.java:81)
>>> at org.apache.maven.lifecycle.internal.builder.singlethreaded.S
>>> ingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>>> at 
>>> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>>>
>>> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
>>> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
>>> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
>>> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
>>> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
>>> at org.apache.maven.cli.Ma

Re: Doxia Macros

[Plamen Totev]

And one last thing - `AsciidoctorParser` actually extends
`org.apache.maven.doxia.module.xhtml.XhtmlParser` but I don't think it
delegates the parsing to it in any way. It's strange why it extends it
then. Maybe I'm missing something.

On Tue, Jun 13, 2017 at 11:49 PM, Plamen Totev <plamen.iv.to...@gmail.com>
wrote:

> Hmm, now that I took a quick look at the `AsciidoctorParser` it looks like
> what I've said does not apply for the Asciidoctor Maven Plugin.
>
> `AsciidoctorParser` is actually cheating a bit - it does not use the
> `Sink` API. It just parses the AsciiDoc content and dumps it as raw text
> [1]. One way to enable the macros is to use the same strategy as the
> `MarkdownParser` [2]. it just converts the Markdown to HTML and then uses
> modified version of the Doxia `XhtmlParser` [3] to actually parse the
> content. This way you'll get the macros for free given the output from the
> AsciiDoc could contain HTML comments like this one:
>
> ```
> 
> ```
>
> [1] https://github.com/asciidoctor/asciidoctor-maven-
> plugin/blob/master/src/main/java/org/asciidoctor/maven/
> site/AsciidoctorParser.java#L84
> [2] http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-
> modules/doxia-module-markdown/src/main/java/org/apache/
> maven/doxia/module/markdown/MarkdownParser.java?view=markup#l109
> [3] http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-
> modules/doxia-module-markdown/src/main/java/org/apache/
> maven/doxia/module/markdown/MarkdownParser.java?view=markup#l250
>
> On Tue, Jun 13, 2017 at 11:26 PM, Plamen Totev <plamen.iv.to...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I have limited understanding on the matter and what I going to say may
>> not be 100% correct, but I hope it will help you to get started.
>>
>> > I'd like to work on supporting macros for the asciidoctor-maven-plugin.
>> Any
>> > idea on what to look at? What defines whether a macro is supported or
>> not?
>> `
>> The ATP parser is good location to start looking at.
>> AptParser.MacroBlock[1] handles the macros for the APT format. I don't
>> think there is a flag that indicates if given `Parser` supports macros
>> or not. It's up to the `Parser` implementation to parse the macro
>> parameters and to execute the macro. So it's up to you to extract the
>> macro id (name) and the params for it from the Asciidoc text.
>>
>> `AbstractParser#executeMacro(String macroId, MacroRequest request,
>> Sink sink)` [2]  will execute the macro on the given sink. So
>> essentially you only need to create a  MacroRequest instance and pass
>> it to the `executeMacro` method together with the macro id and the
>> sink. The MacroRequest constructor [3] takes four parameters:
>>
>> * String sourceContent - this is the original content
>> * AbstractParser parser - a parser that could parse the sourceContent
>> * Map<String, Object> param - params for the macro
>> * File base - the current base directory
>>
>> Some of the macros (such as Table of content for example) need to
>> parse the content again. That is why you have to pass `sourceContent`
>> and `parser`. Just be careful to avoid infinite recursion. There is
>> `AbstractParser#isSecondParsing` flag that can help you with that.
>> Make sure you're not executing any macros on the second parsing (or at
>> least that is what the APT parser is doing, Maybe there is a better
>> way to avoid infinite recursion or similar problems, but this should
>> do I think).
>>
>> Hope this helps you.
>>
>> Regards,
>> Plamen Totev
>>
>> [1] http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-m
>> odules/doxia-module-apt/src/main/java/org/apache/maven/doxia
>> /module/apt/AptParser.java?view=markup#l2871
>> [2] http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-c
>> ore/src/main/java/org/apache/maven/doxia/parser/AbstractPars
>> er.java?view=markup#l129
>> [3] http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-c
>> ore/src/main/java/org/apache/maven/doxia/macro/MacroRequest.
>> java?view=markup#l60
>>
>>
>> >
>> > --
>> > Regards, Petar!
>> > Karlovo, Bulgaria.
>> > ---
>> > Public PGP Key at:
>> > http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
>> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>
>
>

Re: Doxia Macros

[Plamen Totev]

Hmm, now that I took a quick look at the `AsciidoctorParser` it looks like
what I've said does not apply for the Asciidoctor Maven Plugin.

`AsciidoctorParser` is actually cheating a bit - it does not use the `Sink`
API. It just parses the AsciiDoc content and dumps it as raw text [1]. One
way to enable the macros is to use the same strategy as the
`MarkdownParser` [2]. it just converts the Markdown to HTML and then uses
modified version of the Doxia `XhtmlParser` [3] to actually parse the
content. This way you'll get the macros for free given the output from the
AsciiDoc could contain HTML comments like this one:

```

```

[1]
https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/master/src/main/java/org/asciidoctor/maven/site/AsciidoctorParser.java#L84
[2]
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java?view=markup#l109
[3]
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java?view=markup#l250

On Tue, Jun 13, 2017 at 11:26 PM, Plamen Totev <plamen.iv.to...@gmail.com>
wrote:

> Hi,
>
> I have limited understanding on the matter and what I going to say may
> not be 100% correct, but I hope it will help you to get started.
>
> > I'd like to work on supporting macros for the asciidoctor-maven-plugin.
> Any
> > idea on what to look at? What defines whether a macro is supported or
> not?
> `
> The ATP parser is good location to start looking at.
> AptParser.MacroBlock[1] handles the macros for the APT format. I don't
> think there is a flag that indicates if given `Parser` supports macros
> or not. It's up to the `Parser` implementation to parse the macro
> parameters and to execute the macro. So it's up to you to extract the
> macro id (name) and the params for it from the Asciidoc text.
>
> `AbstractParser#executeMacro(String macroId, MacroRequest request,
> Sink sink)` [2]  will execute the macro on the given sink. So
> essentially you only need to create a  MacroRequest instance and pass
> it to the `executeMacro` method together with the macro id and the
> sink. The MacroRequest constructor [3] takes four parameters:
>
> * String sourceContent - this is the original content
> * AbstractParser parser - a parser that could parse the sourceContent
> * Map<String, Object> param - params for the macro
> * File base - the current base directory
>
> Some of the macros (such as Table of content for example) need to
> parse the content again. That is why you have to pass `sourceContent`
> and `parser`. Just be careful to avoid infinite recursion. There is
> `AbstractParser#isSecondParsing` flag that can help you with that.
> Make sure you're not executing any macros on the second parsing (or at
> least that is what the APT parser is doing, Maybe there is a better
> way to avoid infinite recursion or similar problems, but this should
> do I think).
>
> Hope this helps you.
>
> Regards,
> Plamen Totev
>
> [1] http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-
> modules/doxia-module-apt/src/main/java/org/apache/maven/
> doxia/module/apt/AptParser.java?view=markup#l2871
> [2] http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-
> core/src/main/java/org/apache/maven/doxia/parser/AbstractParser.java?view=
> markup#l129
> [3] http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-
> core/src/main/java/org/apache/maven/doxia/macro/
> MacroRequest.java?view=markup#l60
>
>
> >
> > --
> > Regards, Petar!
> > Karlovo, Bulgaria.
> > ---
> > Public PGP Key at:
> > http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

Re: Doxia Macros

[Plamen Totev]

Hi,

I have limited understanding on the matter and what I going to say may
not be 100% correct, but I hope it will help you to get started.

> I'd like to work on supporting macros for the asciidoctor-maven-plugin. Any
> idea on what to look at? What defines whether a macro is supported or not?
`
The ATP parser is good location to start looking at.
AptParser.MacroBlock[1] handles the macros for the APT format. I don't
think there is a flag that indicates if given `Parser` supports macros
or not. It's up to the `Parser` implementation to parse the macro
parameters and to execute the macro. So it's up to you to extract the
macro id (name) and the params for it from the Asciidoc text.

`AbstractParser#executeMacro(String macroId, MacroRequest request,
Sink sink)` [2]  will execute the macro on the given sink. So
essentially you only need to create a  MacroRequest instance and pass
it to the `executeMacro` method together with the macro id and the
sink. The MacroRequest constructor [3] takes four parameters:

* String sourceContent - this is the original content
* AbstractParser parser - a parser that could parse the sourceContent
* Map<String, Object> param - params for the macro
* File base - the current base directory

Some of the macros (such as Table of content for example) need to
parse the content again. That is why you have to pass `sourceContent`
and `parser`. Just be careful to avoid infinite recursion. There is
`AbstractParser#isSecondParsing` flag that can help you with that.
Make sure you're not executing any macros on the second parsing (or at
least that is what the APT parser is doing, Maybe there is a better
way to avoid infinite recursion or similar problems, but this should
do I think).

Hope this helps you.

Regards,
Plamen Totev

[1] 
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-modules/doxia-module-apt/src/main/java/org/apache/maven/doxia/module/apt/AptParser.java?view=markup#l2871
[2] 
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/parser/AbstractParser.java?view=markup#l129
[3] 
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/main/java/org/apache/maven/doxia/macro/MacroRequest.java?view=markup#l60


>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

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

Plexus Archiver handling of symbolic links on Windows

[Plamen Totev]

Hello,

There is discussion on Plexus Archiver about symbolic links and
Windows[1]. Currently if a file set is added to an archive and the OS
is Windows the symbolic links are followed. That is, instead of the
symbolic links, the resulting archive contains the files they point
to. For some time Java was not able to work with symbolic links on
Windows, but that is no longer the case. Windows supports symbolic
links since Vista and if you have the required permissions Java works
perfectly fine with the them.

There is proposal to change the default behavior of Plexus Archiver -
to make it consistent across the OSes and to not follow the symbolic
links when a file set is added to an archive. Then regardless of the
OS, the resulting archive will contain the symbolic links and not
copies of the files they point to.

I have two concerns about that.

The first one is the path separator. A symbolic links on Windows will
look something like `src\fileR.txt`. When the archive is extracted on
Linux the symbolic link will be broken. It will point to the
`src\fileR.txt` file (a perfectly valid name for a file on Linux) and
not to the `fileR.txt` file inside the `src` directory. So I think we
should normalize the paths on Windows. The link added should point to
`src/fileR.txt`. I think this will work both on Windows and Linux, but
I'm not 100% sure. Would be great if somebody with more experience on
the matter could confirm that.

My second concern is the effect that this change will have on Maven
plug-ins such as the Assembly plug-in. Imagine a project that creates
a distribution package and one of the directories contains some
symbolic links. With the current implementation if the package is
created on Windows, it will contains duplicated files. In many cases
that could be a desired behavior. By default you have to be admin user
to create symbolic links and many tools on Windows does not support
symbolic links. Including some (if not most) of the popular archivers.
If we change the Plexus Archiver default behavior we may broke
projects like this one. The resulting Windows package will contain
symbolic links but this may result in poor user experience as many
archive programs will no handle it properly. What do you think? Will
such a change in the Plexus Archive break projects or my concern is
undue? Probably the benefits of having consistent behavior on all OSes
are worth taking the risk?

What do you think? Do you have any other concerns related to the
support of symbolic links on Windows.

Regards,
Plamen Totev

p.s. Microsoft is trying to improve the support for symbolic links.
The Windows 10 Creators update will contain some improvements that
will allow non-admin users to create symbolic links and Microsoft is
"working with the owners of open-source community tools such as Git
and npm so they know symlink improvements are coming and can make the
necessary changes to better support symlinks on Windows" [2].


[1] https://github.com/codehaus-plexus/plexus-archiver/issues/47
[2] https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10

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

Re: Looking for a collaborator to work on an experimental fork of the maven-dependency-plugin

[Plamen Totev]

On Jun 5, 2017 20:51, "Paul Hammant" <p...@hammant.org> wrote:

The publishing binaries to Github
isn't the problem I'm trying to solve - it is the acquisition of deps as
builds needs them.  Want to take this offline ?


- Paul


That is interesting problem to solve. Unfortunatelly I don' t have the time
to participate right now. But I'll follow the development with interest.

Regards,
Plamen Totev

Re: Looking for a collaborator to work on an experimental fork of the maven-dependency-plugin

[Plamen Totev]

Hi,

I think I had a similar idea. Could you please elaborate what you want to
achieve? Using GitHub as Maven repository?

I was looking at the matter myself. I didn't spend much time so I have only
basic understanding of the problems involved and how to solve them.
As far I know there are (even several) Maven plug-ins that allows you to
publish Maven artifact to GitHub using the Releases API. But I didn't find
a way to use GitHub Releases as Maven Repository.

In any case I think the Wagon plug-in is the one that provides the transport
and the one that should be extended in order to be able to reprieve
artifacts from a new service, not the Dependency plug-in.

Regards,
Plamen Totev

On Jun 4, 2017 14:23, "Paul Hammant" <p...@hammant.org> wrote:

> So I have 27 releases of XStream unzipped and pushed to
> https://github.com/paul-hammant/mc-xs-classes
>
> (8.4M of Jars is now 2.4M of bare .git repo)
>
> All the jars are still available - here -
> https://github.com/paul-hammant/mc-xs-classes/releases
>
> Perfect except:
>
>
>1. .zip suffix instead of .jar
>2. there's a pesky root folder inside the zip, that matches the tag name
>(GitHub's policy I guess for downloads).
>3. the signatures won't match those for the originals up on 'Central.
>
> I want to fork (experimentally) maven-dependency-plugin (it's in Subversion
> now, but the fork should be on GitHub of course), and sprinkle in some
> https://github.com/zeroturnaround/zt-zip in order to (1) rename the zip on
> download from GitHub, and (2) remove the root folder inside the zip without
> a mechanical unzip/rezip ... then put theresult in ~/.m2/repository/ as
> normal.
>
> There's probably some pom.xml creativity needed too.
>
> Any takers?
>
> - Paul
>

RE: Heads up, Plexus IO/Archiver is going Java 7

[Plamen Totev]

Hi,

As the branch is now merged is there anything that blocks the release of
Plexus IO 3.0.0?

Regards,
Plamen Totev

Developing fix that spans across several Apache projects

[Plamen Totev]

Hi,

There is an issue in the Maven Assembly Plugin cause by a bug in the 
Plexus Archiver - 
https://github.com/codehaus-plexus/plexus-archiver/issues/53. To fix the 
issue I've created a patch for Apache Common Compress - 
https://issues.apache.org/jira/browse/COMPRESS-375


My understanding is that in order to fix the issue three releases are 
required. First the Apache Common Compress should be released, then 
Plexus Archiver and finally the Maven Assembly plugin. I'm new to 
contributing to open source project in general so I'll be very grateful 
if somebody could tell me more about the procedure in such cases and how 
should I handle them. Excuse me if this question was asked already, but 
I didn't manage to find any information.


And maybe a bit off-topic. My proposed fix introduces a backward 
incompatible change in Plexus Archiver. You could take a look at the 
proposed changes here - 
https://github.com/plamentotev/plexus-archiver/commit/c493756f86acbe5d64084a875045f00e905c8136. 
What do you think? Tt needs a polish such as better javadocs for the 
ConcurrentJarCreator constructor and more test cases, but you could get 
an idea about the patch. Does this change require major version change 
in Plexus Archiver? Not quite sure if ConcurrentJarCreator is part of 
the public interface of the library.


Thanks,
Plamen Totev



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

Plexus Archiver Replaces the Original Zip Archive on Update

[Plamen Totev]

Hi,

There is an issue on Plexus Archiver about that when 
ZipArchiver.setUpdateMode() is set to true, the original archive is 
overridden instead of updated - 
https://github.com/codehaus-plexus/plexus-archiver/issues/2 As the issue 
is over an year old and it did not receive much attention I was 
wondering if there are any Maven plugins affected by it.


Regards,

Plamen Totev


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

Questions about how to contribute to Plexus

[Plamen Totev]

Hi,

Recently I was granted write access to the plexus-io and plexus-archiver 
GitHub repositories. I'm not sure where I can found any guides for 
contributors. Also I can't found the plexus project mail list - not sure 
where to write if I have questions related to the project. I would love 
to contribute to the project and help it with the maintenance but not 
sure about what to do so I'll be very grateful if you could give me some 
directions where I can get more info or help.


Thanks,

Plamen Totev

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