Paypal Declares Latest Release Pom in Maven Central

[Petar Tahchiev]

Hi devs,

the official paypal merchantsdk-java pom.xml here:
https://repo1.maven.org/maven2/com/paypal/sdk/merchantsdk/2.15.122/merchantsdk-2.15.122.pom
declares the following dependency:



com.paypal.sdk
paypal-core
LATEST



It also lists this repository:


sonatype-nexus-staging
Nexus Release Repository

https://oss.sonatype.org/service/local/staging/deploy/maven2/




which is password protected. As a result every time I build a project with
the merchantsdk dependency I get the following super  annoying warnings:
---
Downloading from sonatype-nexus-staging:
https://oss.sonatype.org/service/local/staging/deploy/maven2/com/paypal/sdk/paypal-core/maven-metadata.xml
[WARNING] Could not transfer metadata
com.paypal.sdk:paypal-core/maven-metadata.xml from/to
sonatype-nexus-staging (
https://oss.sonatype.org/service/local/staging/deploy/maven2/): Not
authorized
[WARNING] Failure to transfer com.paypal.sdk:paypal-core/maven-metadata.xml
from https://oss.sonatype.org/service/local/staging/deploy/maven2/ was
cached in the local repository, resolution will not be reattempted until
the update interval of sonatype-nexus-staging has elapsed or updates are
forced. Original error: Could not transfer metadata
com.paypal.sdk:paypal-core/maven-metadata.xml from/to
sonatype-nexus-staging (
https://oss.sonatype.org/service/local/staging/deploy/maven2/): Not
authorized

Moreover when my network is down the build takes eternity before it fails
with exception. And then I have to tell all my colleagues to build it with
-o

Is there any way to tell Paypal to update their pom.xml and upload a new
version?
There's a 2-year old issue here:
https://github.com/paypal/merchant-sdk-java/issues/46
but nobody seems to take a notice.
Is there any official way to contact Paypal and ask them to fix it?

-- 
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: [maven-release] branch master updated: Expose dependency.dev and dependency.rel properties

[Petar Tahchiev]

I think it's fine. I don't think it's going to break anything. For some
reason these changes got left behind and I had to add them.

На нд, 27.10.2019 г. в 21:00 ч. Robert Scholte 
написа:

> I thought this was already fixed (as the issue is closed). I remember we
> had a discussion about the solution, just want to be sure you don't break
> anything. This should already have been covered by an integrationtest, so
> I'm suprised by this change.
> On 27-10-2019 19:46:25, Petar Tahchiev  wrote:
> Hi Robert,
>
> yes I noticed today it somehow was left behind. As the message in the
> commit says it is for MRELEASE-985 and we need it to be able to override
> certain dependency versions from command line.
>
> На нд, 27.10.2019 г. в 20:35 ч. Robert Scholte
> написа:
>
> > Hi Petar,
> >
> > Is this related to https://issues.apache.org/jira/browse/MRELEASE-985 ?
> >
> > Robert
> >
> > On 27-10-2019 08:22:12, ptahch...@apache.org wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > ptahchiev pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/maven-release.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> > new d371cc0 Expose dependency.dev and dependency.rel properties
> > d371cc0 is described below
> >
> > commit d371cc0d3e76190f9f92781d9921d6e7e0d9acbd
> > Author: petar.tahchiev
> > AuthorDate: Sun Oct 27 09:17:14 2019 +0200
> >
> > Expose dependency.dev and dependency.rel properties
> >
> > As part of this: https://github.com/apache/maven-release/pull/18 and
> > this: https://issues.apache.org/jira/browse/MRELEASE-985
> > we need to check if the command line property starts with dependency.dev
> > or dependency.rel to be able to override the value of the
> > property.
> > ---
> > .../org/apache/maven/shared/release/config/ReleaseUtils.java | 10
> > ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git
> >
> a/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ReleaseUtils.java
> >
> b/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ReleaseUtils.java
> >
> > index 3b4f14b..9200ee2 100644
> > ---
> >
> a/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ReleaseUtils.java
> >
> > +++
> >
> b/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ReleaseUtils.java
> >
> > @@ -172,6 +172,16 @@ public class ReleaseUtils
> > builder.addDevelopmentVersion( property.substring( "project.dev
> .".length()
> > ),
> > properties.getProperty( property ) );
> > }
> > + else if ( property.startsWith( "dependency.rel." ) )
> > + {
> > + builder.addDependencyReleaseVersion( property.substring(
> > "dependency.rel.".length() ),
> > + properties.getProperty( property ) );
> > + }
> > + else if ( property.startsWith( "dependency.dev." ) )
> > + {
> > + builder.addDependencyDevelopmentVersion( property.substring( "
> > dependency.dev.".length() ),
> > + properties.getProperty( property ) );
> > + }
> > else if ( property.startsWith( "project.scm." ) )
> > {
> > int index = property.lastIndexOf( '.' );
> >
> >
>
> --
> 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
>


-- 
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: [maven-release] branch master updated: Expose dependency.dev and dependency.rel properties

[Petar Tahchiev]

Hi Robert,

yes I noticed today it somehow was left behind. As the message in the
commit says it is for MRELEASE-985 and we need it to be able to override
certain dependency versions from command line.

На нд, 27.10.2019 г. в 20:35 ч. Robert Scholte 
написа:

> Hi Petar,
>
> Is this related to https://issues.apache.org/jira/browse/MRELEASE-985 ?
>
> Robert
>
> On 27-10-2019 08:22:12, ptahch...@apache.org  wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> ptahchiev pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/maven-release.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new d371cc0 Expose dependency.dev and dependency.rel properties
> d371cc0 is described below
>
> commit d371cc0d3e76190f9f92781d9921d6e7e0d9acbd
> Author: petar.tahchiev
> AuthorDate: Sun Oct 27 09:17:14 2019 +0200
>
> Expose dependency.dev and dependency.rel properties
>
> As part of this: https://github.com/apache/maven-release/pull/18 and
> this: https://issues.apache.org/jira/browse/MRELEASE-985
> we need to check if the command line property starts with dependency.dev
> or dependency.rel to be able to override the value of the
> property.
> ---
> .../org/apache/maven/shared/release/config/ReleaseUtils.java | 10
> ++
> 1 file changed, 10 insertions(+)
>
> diff --git
> a/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ReleaseUtils.java
> b/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ReleaseUtils.java
>
> index 3b4f14b..9200ee2 100644
> ---
> a/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ReleaseUtils.java
>
> +++
> b/maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ReleaseUtils.java
>
> @@ -172,6 +172,16 @@ public class ReleaseUtils
> builder.addDevelopmentVersion( property.substring( "project.dev.".length()
> ),
> properties.getProperty( property ) );
> }
> + else if ( property.startsWith( "dependency.rel." ) )
> + {
> + builder.addDependencyReleaseVersion( property.substring(
> "dependency.rel.".length() ),
> + properties.getProperty( property ) );
> + }
> + else if ( property.startsWith( "dependency.dev." ) )
> + {
> + builder.addDependencyDevelopmentVersion( property.substring( "
> dependency.dev.".length() ),
> + properties.getProperty( property ) );
> + }
> else if ( property.startsWith( "project.scm." ) )
> {
> int index = property.lastIndexOf( '.' );
>
>

-- 
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: JSR250 in the lib

[Petar Tahchiev]

+1 on Tibor's proposal

На пн, 14.10.2019 г. в 13:03 ч. Tibor Digana 
написа:

> All these annotations are for Java EE containers and application servers.
> A clear solution in 4.0 or 5.0 would be to develop our own annotations for
> Maven Domain (not EE domain) within or Java package.
>
> This way we would reach:
> + annotations looking similar to EE annotations
> + isolation on the package level
> + the purpose of the annotations would match specific Maven domain
> + the JavaDoc would not be EE specific anymore
>
> Many coleagues have negative opinion to my proposal but this was only mine
> view.
>
> On Mon, Oct 14, 2019 at 11:40 AM Stuart McCulloch 
> wrote:
>
> > The JSR-250 API was exposed in
> > https://issues.apache.org/jira/browse/MNG-6084
> >
> > It provides the @PostConstruct, @PreDestroy, and @Priority standard
> > extension annotations for use by plugin components.
> >
> > Isolating that API would affect any plugin components that rely on
> MNG-6084
> > - they would then need to revert back to Initializable and Disposable
> from
> > the Plexus API (although note that the benefit of using a javax API is
> that
> > it makes components more reusable, especially when they come from outside
> > the Maven ecosystem and just happen to be used in a Maven plugin.)
> >
> > The best solution would be to either upgrade that dependency - or
> > alternatively just expose the @PostConstruct, @PreDestroy, and @Priority
> > annotation types rather than the whole package.
> >
> > On Mon, 14 Oct 2019 at 06:01, Romain Manni-Bucau 
> > wrote:
> >
> > > Guess it just comes from guice or friends and since they dont support
> > > recent API it was not upgraded.
> > > We can upgrade it or just isolate it IMO - but requires some careness
> > since
> > > custom components can use it so needs an evolution to toggle it
> probably.
> > >
> > > Le lun. 14 oct. 2019 à 03:43, Tibor Digana  a
> > > écrit :
> > >
> > > > It is a similar issue to the problem with "javax.inject" API.
> > > > What about relocating these two APIs to a package "org.apache.maven"?
> > Any
> > > > thoughts?
> > > >
> > > > On Mon, Oct 14, 2019 at 12:11 AM Petar Tahchiev <
> paranoia...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hello guys,
> > > > >
> > > > > I just decided to upgrade my build from 3.5.0 to 3.6.2 last night
> > and I
> > > > > stumbled across multiple problems, latest one being the following
> > > > > exception:
> > > > >
> > > > > Nested exception is java.lang.NoSuchMethodError:
> > > > > javax.annotation.Resource.lookup()Ljava/lang/String;
> > > > >
> > > > > Seems like maven 3.6.2 comes with jsr-250-api-1.0.jar in the lib/
> > > folder
> > > > > and that seems to cause problems for me because I have moneta in my
> > > > > classpath which brings newer version of jsr250:
> > > > >
> > > > > [INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @
> > drmartens
> > > > ---
> > > > > [INFO] com.demo:drmartens:war:1.0-SNAPSHOT
> > > > > [INFO] \-
> > > > >
> > > > >
> > > >
> > >
> >
> com.nemesis.platform:nemesis-platform-core:jar:2.1.67.BUILD-SNAPSHOT:compile
> > > > > [INFO]\- org.javamoney:moneta:pom:1.3:compile
> > > > > [INFO]   \-
> > javax.annotation:javax.annotation-api:jar:1.3.2:compile
> > > > > [INFO]
> > > > >
> > >
> 
> > > > >
> > > > > So I was able to fix this following this recommendation:
> > > > >
> > > > >
> > > >
> > >
> >
> https://stackoverflow.com/questions/52607814/how-to-remove-a-maven-lib-jsr250-api-1-0-jar-from-the-plugin-classpath-jetty
> > > > > using extensions, but I was wondering: why do we need the JSR250 in
> > the
> > > > lib
> > > > > folder? Also why do we need such an old version?
> > > > > --
> > > > > 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
> > > > >
> > > >
> > >
> >
>


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

JSR250 in the lib

[Petar Tahchiev]

Hello guys,

I just decided to upgrade my build from 3.5.0 to 3.6.2 last night and I
stumbled across multiple problems, latest one being the following exception:

Nested exception is java.lang.NoSuchMethodError:
javax.annotation.Resource.lookup()Ljava/lang/String;

Seems like maven 3.6.2 comes with jsr-250-api-1.0.jar in the lib/ folder
and that seems to cause problems for me because I have moneta in my
classpath which brings newer version of jsr250:

[INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @ drmartens ---
[INFO] com.demo:drmartens:war:1.0-SNAPSHOT
[INFO] \-
com.nemesis.platform:nemesis-platform-core:jar:2.1.67.BUILD-SNAPSHOT:compile
[INFO]\- org.javamoney:moneta:pom:1.3:compile
[INFO]   \- javax.annotation:javax.annotation-api:jar:1.3.2:compile
[INFO]


So I was able to fix this following this recommendation:
https://stackoverflow.com/questions/52607814/how-to-remove-a-maven-lib-jsr250-api-1-0-jar-from-the-plugin-classpath-jetty
using extensions, but I was wondering: why do we need the JSR250 in the lib
folder? Also why do we need such an old version?
-- 
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

Maven release plugin Xmx Xms environment variables

[Petar Tahchiev]

Hi all,

just a quick question. I have a project that I'm releasing using the
maven-release-plugin, but every time I call release:prepare the build fails
with OutofMemoryError. I tried setting the MAVEN_OPTS to "-Xmx2G" but
honestly I don't think it has any effect because after the build ends I get
this file

-rw---  1 tomcat tomcat 3.3G Oct  1 09:59 java_pid15462.hprof

which clearly is 3.3G

I was looking at the code of the maven-release-plugin and I don't see a way
to specify the java memory options of the forked process. Is this a missing
feature? Or have I missed something? How can one specify the jvmArgs of the
forked process?

Thank you.
-- 
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: MRELEASE-985(again)

[Petar Tahchiev]

Hello,

if somebody would confirm my changes are OK, I'd like to perform a release
of the maven-release-plugin - the last release is almost 4 years old.

На нд, 21.04.2019 г. в 13:29 ч. Petar Tahchiev 
написа:

> Hi Robert,
> and thank you for your response. I have pushed a test which fails if I
> revert my changes. The test passes with my changes. Please could someone
> have a look at what I have changed and if it is OK.
>
> Thank you.
>
> На нд, 21.04.2019 г. в 12:27 ч. Robert Scholte 
> написа:
>
>> Hi Petar,
>>
>> IIRC the idea behind the original setup was to keep the original builder
>> immutable and to keep a clear separation between what was configured by
>> descriptor and what by commandline.
>> And IIRC there's a set of properties that should NEVER be overridden via
>> commandline.
>>
>> Also, if this is that critical for you, remember to add a test. You've
>> seen that the codebased has changed a lot, verifying changes with tests is
>> the only way to ensure the refactoring was done properly.
>>
>>
>> thanks,
>> Robert
>> On 21-4-2019 08:38:37, Petar Tahchiev  wrote:
>> Hey guys,
>>
>> a while ago I raised this issue
>> https://issues.apache.org/jira/browse/MRELEASE-985
>>
>> and also I made a pull-request:
>> https://github.com/apache/maven-release/pull/18
>>
>> but it was closed, because I believe after a few years the code was very
>> much out of sync with the master.
>>
>> However, I checked the master and seems like there is a way to override
>> the
>> SNAPSHOT dependencies from the command with a command like this:
>>
>> mvn org.apache.maven.plugins:maven-release-plugin:3.0.0-SNAPSHOT:prepare
>> -DdryRun=true -Ddependency.com.nemesis:bom.release=2.0.1.RELEASE
>> -Ddependency.com.nemesis:bom.development=2.1.3-BUILD-SNAPSHOT -e -B
>>
>> However, when I tried it I got the same error:
>>
>> Caused by: org.apache.maven.shared.release.ReleaseFailureException: Can't
>> release project due to non released dependencies :
>> com.nemesis:bom:pom:2.1.0.BUILD-SNAPSHOT
>> in project 'Nemesis Platform'
>> (com.nemesis:platform:pom:2.1.0.BUILD-SNAPSHOT)
>>
>> Then I started digging and saw that in the DefaultReleaseManager the
>> command-line properties are copied to a new ReleaseBuilder using
>> ReleaseUtils.copyPropertiesToReleaseDescriptor and then this new release
>> builder is ignored.
>> Furthermore the CheckDependenciesSnapshotsPhase was not interested if the
>> dependency was resolved from the command-line and was simply checking if
>> it
>> is a SNAPSHOT dependency.
>>
>> With those two small changes my build works fine. Can someone of you have
>> a
>> look at my PR:
>>
>> https://github.com/apache/maven-release/pull/28
>>
>> and confirm that the change in DefaultReleaseManager doesn't break
>> anything. All the tests pass. If you confirm that it is OK I can add a
>> test
>>
>> Thank you.
>> --
>> 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
>>
>
>
> --
> 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
>


-- 
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: MRELEASE-985(again)

[Petar Tahchiev]

Hi Robert,
and thank you for your response. I have pushed a test which fails if I
revert my changes. The test passes with my changes. Please could someone
have a look at what I have changed and if it is OK.

Thank you.

На нд, 21.04.2019 г. в 12:27 ч. Robert Scholte 
написа:

> Hi Petar,
>
> IIRC the idea behind the original setup was to keep the original builder
> immutable and to keep a clear separation between what was configured by
> descriptor and what by commandline.
> And IIRC there's a set of properties that should NEVER be overridden via
> commandline.
>
> Also, if this is that critical for you, remember to add a test. You've
> seen that the codebased has changed a lot, verifying changes with tests is
> the only way to ensure the refactoring was done properly.
>
>
> thanks,
> Robert
> On 21-4-2019 08:38:37, Petar Tahchiev  wrote:
> Hey guys,
>
> a while ago I raised this issue
> https://issues.apache.org/jira/browse/MRELEASE-985
>
> and also I made a pull-request:
> https://github.com/apache/maven-release/pull/18
>
> but it was closed, because I believe after a few years the code was very
> much out of sync with the master.
>
> However, I checked the master and seems like there is a way to override the
> SNAPSHOT dependencies from the command with a command like this:
>
> mvn org.apache.maven.plugins:maven-release-plugin:3.0.0-SNAPSHOT:prepare
> -DdryRun=true -Ddependency.com.nemesis:bom.release=2.0.1.RELEASE
> -Ddependency.com.nemesis:bom.development=2.1.3-BUILD-SNAPSHOT -e -B
>
> However, when I tried it I got the same error:
>
> Caused by: org.apache.maven.shared.release.ReleaseFailureException: Can't
> release project due to non released dependencies :
> com.nemesis:bom:pom:2.1.0.BUILD-SNAPSHOT
> in project 'Nemesis Platform'
> (com.nemesis:platform:pom:2.1.0.BUILD-SNAPSHOT)
>
> Then I started digging and saw that in the DefaultReleaseManager the
> command-line properties are copied to a new ReleaseBuilder using
> ReleaseUtils.copyPropertiesToReleaseDescriptor and then this new release
> builder is ignored.
> Furthermore the CheckDependenciesSnapshotsPhase was not interested if the
> dependency was resolved from the command-line and was simply checking if it
> is a SNAPSHOT dependency.
>
> With those two small changes my build works fine. Can someone of you have a
> look at my PR:
>
> https://github.com/apache/maven-release/pull/28
>
> and confirm that the change in DefaultReleaseManager doesn't break
> anything. All the tests pass. If you confirm that it is OK I can add a test
>
> Thank you.
> --
> 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
>


-- 
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: [VOTE] Release Apache Maven Archetype Plugin version 3.1.0

[Petar Tahchiev]

I tested with our project. Seems good. +1 from me

На сб, 20.04.2019 г. в 21:01 ч. Robert Scholte 
написа:

> Hi,
>
> We solved 13 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317122=12340346=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317122%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1499/ [
> https://repository.apache.org/content/repositories/maven-1499/]
>
> https://repository.apache.org/content/repositories/maven-1499/org/apache/maven/archetype/maven-archetype/3.1.0/maven-archetype-3.1.0-source-release.zip
>
> Source release checksum(s):
>
> maven-archetype-3.1.0-source-release.zip sha512: 
> 6dc9b9ac60d945bca4818cb259d07fe5b6bb71ea4befd16490093cccd445def3de02aa3f03d88a2b9c80ceea3f114485f119afed8101adbf27895ca659a199a1
>
> Staging site:
> https://maven.apache.org/archetype-archives\archetype-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1



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

MRELEASE-985(again)

[Petar Tahchiev]

Hey guys,

a while ago I raised this issue
https://issues.apache.org/jira/browse/MRELEASE-985

and also I made a pull-request:
https://github.com/apache/maven-release/pull/18

but it was closed, because I believe  after a few years the code was very
much out of sync with the master.

However, I checked the master and seems like there is a way to override the
SNAPSHOT dependencies from the command with a command like this:

mvn org.apache.maven.plugins:maven-release-plugin:3.0.0-SNAPSHOT:prepare
-DdryRun=true  -Ddependency.com.nemesis:bom.release=2.0.1.RELEASE
-Ddependency.com.nemesis:bom.development=2.1.3-BUILD-SNAPSHOT -e -B

However, when I tried it I got the same error:

Caused by: org.apache.maven.shared.release.ReleaseFailureException: Can't
release project due to non released dependencies :
com.nemesis:bom:pom:2.1.0.BUILD-SNAPSHOT
in project 'Nemesis Platform'
(com.nemesis:platform:pom:2.1.0.BUILD-SNAPSHOT)

Then I started digging and saw that in the DefaultReleaseManager the
command-line properties are copied to a new ReleaseBuilder using
ReleaseUtils.copyPropertiesToReleaseDescriptor and then this new release
builder is ignored.
Furthermore the CheckDependenciesSnapshotsPhase was not interested if the
dependency was resolved from the command-line and was simply checking if it
is a SNAPSHOT dependency.

With those two small changes my build works fine. Can someone of you have a
look at my PR:

https://github.com/apache/maven-release/pull/28

and confirm that the change in DefaultReleaseManager doesn't break
anything. All the tests pass. If you confirm that it is OK I can add a test

Thank you.
-- 
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

Maven and TTY terminal

[Petar Tahchiev]

Hi guys,

my setup is Ubuntu Linux and Java8. I'm trying to use JLine from Maven to
get a TerminalBuild and determine the size of the command line. So JLine
has this code inside TerminalBuilder;

Pty pty = load(JansiSupport.class).current();

private  S load(Class clazz) {
return ServiceLoader.load(clazz, clazz.getClassLoader()).iterator().next();
}

When I call JBuilder from one of my annotation processors during
compilation, then Pty is successfully created and so I get a
TerminalBuilder and it all works fine. However, when I call it from one of
my JUnit tests the code throws this exception when .current() is invoked:

java.io.IOException: Not a tty
at
org.jline.terminal.impl.jansi.linux.LinuxNativePty.current(LinuxNativePty.java:29)
at
org.jline.terminal.impl.jansi.JansiSupportImpl.current(JansiSupportImpl.java:54)
at org.jline.terminal.TerminalBuilder.doBuild(TerminalBuilder.java:340)

JLine can also use JNA, but when I added the JNA dependency the story is
the same - when running it from surefire plugin the exception is:

com.sun.jna.LastErrorException: [25] Inappropriate ioctl for device
at com.sun.jna.Native.invokeVoid(Native Method)
at com.sun.jna.Function.invoke(Function.java:414)
at com.sun.jna.Function.invoke(Function.java:360)

Do you know why this happens? Is there any setting that I can set on the
surefire plugin to avoid these types of error?
-- 
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: Access Rights

[Petar Tahchiev]

Thanks Robert, it works fine now.

2018-05-25 13:01 GMT+03:00 Robert Scholte <rfscho...@apache.org>:

> Please read https://gitbox.apache.org/setup/
>
> thanks,
> Robert
>
>
> On Fri, 25 May 2018 11:57:31 +0200, Petar Tahchiev <paranoia...@gmail.com>
> wrote:
>
> Hi guys,
>>
>> I just noted the maven archetype repository is now on github:
>>
>> https://github.com/apache/maven-archetype
>>
>> I was working on a fix for:
>> https://issues.apache.org/jira/browse/ARCHETYPE-530 but I can't push my
>> changes. Do you know who should I talk to, in order to get access rights
>> (my github username is ptahchiev)?
>>
>


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

Access Rights

[Petar Tahchiev]

Hi guys,

I just noted the maven archetype repository is now on github:

https://github.com/apache/maven-archetype

I was working on a fix for:
https://issues.apache.org/jira/browse/ARCHETYPE-530 but I can't push my
changes. Do you know who should I talk to, in order to get access rights
(my github username is ptahchiev)?

-- 
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: Welcome Christian Stein to the Apache Maven Team

[Petar Tahchiev]

Welcome buddy :)

2018-05-08 13:57 GMT+03:00 Olivier Lamy :

> On Tue, 8 May 2018 at 18:49, Christian Stein  wrote:
>
> > On Mon, May 7, 2018 at 11:48 PM Tibor Digana 
> > wrote:
> >
> > > Welcome!
> > > I hope Christian is online.
> > >
> >
> > No, wasn't online when you wrote the mail.
> >
> >
> > > We are working on JUnit5 provider in Surefire together and I see we
> have
> > > quite a good progress step by step. So I think we will produce a new
> > > version 2.22.0.
> >
> >
> > Would be cool if we can have the 2.22 release this month. :)
> >
>
> Oh yes would be really awesome!!!
>
>
> >
> > Cheers,
> > Christian
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>



-- 
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: [VOTE] Release Apache Maven Doxia version 1.8

[Petar Tahchiev]

+1 from me.

2017-12-21 10:30 GMT+02:00 Hervé BOUTEMY :

> one vote still missing...
>
> Regards,
>
> Hervé
>
> Le dimanche 17 décembre 2017, 17:36:53 CET Hervé BOUTEMY a écrit :
> > Hi,
> >
> > We solved 19 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > projectId=12317230=12334847=Text
> >
> > There are still a couple of issues left in JIRA:
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20DOXIA%20AND
> > %20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1383/
> > https://repository.apache.org/content/repositories/maven-
> 1383/org/apache/
> > maven/doxia/doxia/1.8/doxia-1.8-source-release.zip
> >
> > Source release checksum(s):
> > doxia-1.8-source-release.zip sha1: 97bf435da03dd4a8d5cfc1b0f07265
> 090863cff0
> >
> > Staging site:
> > http://maven.apache.org/doxia/doxia-archives/doxia-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
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: Maven release plugin

[Petar Tahchiev]

Hi Robert,
i'll give it a try. Can you please summarize what needs to be done, or
perhaps point me the right direction?

2017-11-20 21:32 GMT+02:00 Robert Scholte <rfscho...@apache.org>:

> Hi Petar,
>
> would be great if you could pick this up.
> There's enough work I want to finish first, maven-release-plugin is not
> one of them right now.
>
> thanks,
> Robert
>
>
> On Mon, 20 Nov 2017 18:38:56 +0100, Petar Tahchiev <paranoia...@gmail.com>
> wrote:
>
> Hi Robert,
>>
>> any updates on the release-aggregator? Is there anything I can do to help?
>>
>> 2017-06-27 22:43 GMT+03:00 Robert Scholte <rfscho...@apache.org>:
>>
>> Hi Petar,
>>>
>>> This is a clear sign that ${project} should not be used to resolve this.
>>> Instead the pom should be analyzed again and if there's a system property
>>> matching the parent, it should be replaced before loading the parent.
>>> That'll require quite some new lines of code :)
>>> The suggested release-aggregator will require this same feature, so
>>> sooner
>>> or later this must be fixed.
>>>
>>> Robert
>>>
>>>
>>> On Tue, 27 Jun 2017 09:50:37 +0200, Petar Tahchiev <
>>> paranoia...@gmail.com>
>>> wrote:
>>>
>>> Hey guys,
>>>
>>>>
>>>> my pull-request worked fine to not show the prompt to specify a version.
>>>> However, it fails to update snapshot dependency versions when you
>>>> resolve
>>>> the parent to a concrete version.
>>>> Particularly in my case:
>>>>
>>>>
>>>> [BOM]
>>>>  /\
>>>>  [PLATFORM]  [DEMO_STORE]
>>>>-module1 - platform:module1
>>>>-module2 - platform:module2
>>>>  .
>>>>- moduleN- platform:moduleN
>>>>
>>>> The [BOM] defines in dependencyManagement section all the versions of
>>>> the
>>>> modules of the [PLATFORM]. Then the [DEMO_STORE] can reference them
>>>> without
>>>> specifying a version. During release what I do is I first release the
>>>> [BOM], then release the [PLATFORM] and up to here I see no problems. But
>>>> then I try to release the DEMO_STORE] and even though I specify on the
>>>> command line the version of the parent [BOM]:
>>>>
>>>> -Ddependency.com.nemesis:bom.release=1.5.2.RELEASE
>>>> -Ddependency.com.nemesis:bom.development=1.5.3.BUILD-SNAPSHOT
>>>>
>>>>
>>>> it still asks me for versions of dependencies which are specified in the
>>>> released [BOM]. I tried patching the code and specifying a new version
>>>> of
>>>> the parent
>>>>
>>>> project.getParentArtifact().setVersion("1.5.2.RELEASE")
>>>>
>>>> just to see if it works, but the problem is that the dependencies in the
>>>> project are already resolved: when I call project.getDependencies() I
>>>> get
>>>> the SNAPSHOT versions.
>>>>
>>>> Is there any way to reload the project model after I specify a new
>>>> parentVersion()? So that It understands the [BOM] is no longer a
>>>> snapshot
>>>> version.
>>>>
>>>> Thanks
>>>>
>>>> 2017-06-25 12:11 GMT+03:00 Robert Scholte <rfscho...@apache.org>:
>>>>
>>>> MRELEASE-362[1] is probably the matching issue.
>>>>
>>>>> Be aware that some are talking about tagging every module. In most
>>>>> situations I don't like that. If the structure is hierarchical and the
>>>>> root
>>>>> is tagged, then all the modules are already tagged. All tags must be
>>>>> checked out during release:perform, keep that in mind.
>>>>> I see options with a flat structure and with the release-aggregator.
>>>>>
>>>>> Robert
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/MRELEASE-362
>>>>>
>>>>>
>>>>> On Sat, 24 Jun 2017 22:59:48 +0200, Petar Tahchiev <
>>>>> paranoia...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi Paul,
>>>>>
>>>>>
>>>>>> I think you misunderstood. T

Re: Maven release plugin

[Petar Tahchiev]

Hi Robert,

any updates on the release-aggregator? Is there anything I can do to help?

2017-06-27 22:43 GMT+03:00 Robert Scholte <rfscho...@apache.org>:

> Hi Petar,
>
> This is a clear sign that ${project} should not be used to resolve this.
> Instead the pom should be analyzed again and if there's a system property
> matching the parent, it should be replaced before loading the parent.
> That'll require quite some new lines of code :)
> The suggested release-aggregator will require this same feature, so sooner
> or later this must be fixed.
>
> Robert
>
>
> On Tue, 27 Jun 2017 09:50:37 +0200, Petar Tahchiev <paranoia...@gmail.com>
> wrote:
>
> Hey guys,
>>
>> my pull-request worked fine to not show the prompt to specify a version.
>> However, it fails to update snapshot dependency versions when you resolve
>> the parent to a concrete version.
>> Particularly in my case:
>>
>>
>> [BOM]
>>  /\
>>  [PLATFORM]  [DEMO_STORE]
>>-module1 - platform:module1
>>-module2 - platform:module2
>>  .
>>- moduleN- platform:moduleN
>>
>> The [BOM] defines in dependencyManagement section all the versions of the
>> modules of the [PLATFORM]. Then the [DEMO_STORE] can reference them
>> without
>> specifying a version. During release what I do is I first release the
>> [BOM], then release the [PLATFORM] and up to here I see no problems. But
>> then I try to release the DEMO_STORE] and even though I specify on the
>> command line the version of the parent [BOM]:
>>
>> -Ddependency.com.nemesis:bom.release=1.5.2.RELEASE
>> -Ddependency.com.nemesis:bom.development=1.5.3.BUILD-SNAPSHOT
>>
>>
>> it still asks me for versions of dependencies which are specified in the
>> released [BOM]. I tried patching the code and specifying a new version of
>> the parent
>>
>> project.getParentArtifact().setVersion("1.5.2.RELEASE")
>>
>> just to see if it works, but the problem is that the dependencies in the
>> project are already resolved: when I call project.getDependencies() I get
>> the SNAPSHOT versions.
>>
>> Is there any way to reload the project model after I specify a new
>> parentVersion()? So that It understands the [BOM] is no longer a snapshot
>> version.
>>
>> Thanks
>>
>> 2017-06-25 12:11 GMT+03:00 Robert Scholte <rfscho...@apache.org>:
>>
>> MRELEASE-362[1] is probably the matching issue.
>>> Be aware that some are talking about tagging every module. In most
>>> situations I don't like that. If the structure is hierarchical and the
>>> root
>>> is tagged, then all the modules are already tagged. All tags must be
>>> checked out during release:perform, keep that in mind.
>>> I see options with a flat structure and with the release-aggregator.
>>>
>>> Robert
>>>
>>> [1] https://issues.apache.org/jira/browse/MRELEASE-362
>>>
>>>
>>> On Sat, 24 Jun 2017 22:59:48 +0200, Petar Tahchiev <
>>> paranoia...@gmail.com>
>>> wrote:
>>>
>>> Hi Paul,
>>>
>>>>
>>>> I think you misunderstood. The [BOM] is a separate project and the
>>>> [PLATFORM] and [DEMO_STORE] are also separate projects, both of which
>>>> declare as their parent the [BOM].
>>>>
>>>> @Robert: I have added the test-case:
>>>> https://github.com/apache/maven-release/pull/18/commits/
>>>> Release-aggregator is exactly what's missing. Is there an issue I can
>>>> subscribe and track?
>>>>
>>>>
>>>> 2017-06-24 14:15 GMT+03:00 Robert Scholte <rfscho...@apache.org>:
>>>>
>>>> What we're still missing is a release-aggregator, which can release
>>>>
>>>>> multiple release-roots at once. That would probably be the preferred
>>>>> fix,
>>>>> the suggested patch is just an easy work-around.
>>>>> It is still on my todo-list.
>>>>>
>>>>> Robert
>>>>>
>>>>>
>>>>> On Sat, 24 Jun 2017 12:42:22 +0200, Paul Hammant <p...@hammant.org>
>>>>> wrote:
>>>>>
>>>>> Easy to fix.  Have a profile 'platformOnly' in the root module (I'm not
>>>>>
>>>>> sure if 'BOM' should mean anything to me) that inc

Re: [VOTE] Release Apache Maven 3.5.1

[Petar Tahchiev]

+1 - go for it.


2017-09-13 9:04 GMT+03:00 Grzegorz Grzybek :

> Hello
>
> +1 (non-binding) - tested Fuse/Karaf/OSGi projects
>
> regards
> Grzegorz Grzybek
>
> 2017-09-13 8:00 GMT+02:00 Thomas Collignon :
>
> > Hello
> >
> > +1 for me
> >
> > 2017-09-12 20:54 GMT+02:00 Stephen Connolly  > com
> > >:
> >
> > > Have we got any feedback from the embedder integrations yet?
> > >
> > > On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY 
> > wrote:
> > >
> > > > just for the records: it is Windows + Git Bash (MINGW64) only
> > > >
> > > > and there is a chance that adding -Djansi.force=true can force JAnsi
> > > > activation (even if JAnsi fails to detect that it should
> auto-activate)
> > > >
> > > > details on issue in https://issues.apache.org/jira/browse/MNG-6282 ,
> > > and a
> > > > future JAnsi issue...
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a écrit :
> > > > > So that is windows only, or were they lost on other OSes for you.
> > > > >
> > > > > I have colours on linux (via docker) and os-x
> > > > >
> > > > > On 11 September 2017 at 12:35, dejan2...@gmail.com <
> > > dejan2...@gmail.com>
> > > > >
> > > > > wrote:
> > > > > > +1 (conditionally).
> > > > > >
> > > > > > Tested via project that includes dozen of plugins: 1st tier,
> > MojoHaus
> > > > and
> > > > > > few 3rd party plugins (so to say).
> > > > > >
> > > > > > Everything looks good with one notable regression:
> > > > > > https://issues.apache.org/jira/browse/MNG-6282 Console output
> has
> > no
> > > > > > colors (regression in Maven 3.5.1)
> > > > > >
> > > > > > Regards,
> > > > > > Dejan
> > > > > >
> > > > > > On 2017-09-10 17:39, Stephen Connolly
>  > > com
> > > > >
> > > > > >
> > > > > > wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > We solved 25 issues:
> > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > > > >
> > > > > > version=12338964=Text=12316922
> > > > > >
> > > > > > > There are 350 issues left in JIRA for Maven core:
> > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > > > >
> > > > > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > > > > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > > > > >
> > > > > > > Staging repo:
> > > > > > > https://repository.apache.org/content/repositories/maven-1364/
> > > > > > >
> > > > > > > The distributable binaries and sources can be found here:
> > > > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > > > 1364/org/apache/maven/apache-maven/3.5.1/
> > > > > >
> > > > > > > Specifically the zip, tarball and source archives can be found
> > > here:
> > > > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.
> > 1-bin.zip
> > > > > >
> > > > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.
> > > 1-bin.tar.gz
> > > > > >
> > > > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.
> > 1-src.zip
> > > > > >
> > > > > > > https://repository.apache.org/content/repositories/maven-> >
> > > > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5.
> > > 1-src.tar.gz
> > > > > >
> > > > > > > Source release checksum(s):
> > > > > > > apache-maven-3.5.1-src.tar.gz sha1:
> > 9eb821f153c7667194aa11ccd099b7
> > > > > >
> > > > > > bd2059560d
> > > > > >
> > > > > > > apache-maven-3.5.1-src.zip: sha1:
> 121d54b045380a8a4895eb137970ab
> > > > > >
> > > > > > 69e698eb0e
> > > > > >
> > > > > > > Git tag:
> > > > > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=
> commit;h=
> > > > > >
> > > > > > 094e4e31a5af55bb17be87675da41d9aeca062f3
> > > > > >
> > > > > > > Staging site:
> > > > > > > https://maven.apache.org/components/ref/3-LATEST/
> > > > > > >
> > > > > > > Vote open for 72 hours.
> > > > > > >
> > > > > > > [ ] +1
> > > > > > > [ ] +0
> > > > > > > [ ] -1
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Stephen.
> > > > > >
> > > > > > 
> > > -
> > > > > > 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
> > > >
> > > > --
> > > Sent from my phone
> > >
> >
>



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

Re: MNG-6258 and MNG-5457 for 3.5.1

[Petar Tahchiev]

+1

2017-07-14 16:11 GMT+03:00 Arnaud Héritier :

> +1
>
> Le ven. 14 juil. 2017 à 13:54, Robert Scholte  a
> écrit :
>
> > +1
> >
> > On Wed, 12 Jul 2017 21:20:01 +0200, Michael Osipov 
> > wrote:
> >
> > > Who seconds
> > >
> > > [MNG-6258] Upgrade to Maven Resolver 1.1.0
> > > [MNG-5457] Show repository id when downloading or uploading from/to a
> > > remote repository
> > >
> > > for 3.5.1? Both IT runs pass. MNG-5457 requires MNG-6258.
> > >
> > > Michael
> > >
> > > -
> > > 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
> >
> > --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>



-- 
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: Maven release plugin

[Petar Tahchiev]

Hey guys,

my pull-request worked fine to not show the prompt to specify a version.
However, it fails to update snapshot dependency versions when you resolve
the parent to a concrete version.
Particularly in my case:


[BOM]
 /\
 [PLATFORM]  [DEMO_STORE]
   -module1 - platform:module1
   -module2 - platform:module2
     .
   - moduleN- platform:moduleN

The [BOM] defines in dependencyManagement section all the versions of the
modules of the [PLATFORM]. Then the [DEMO_STORE] can reference them without
specifying a version. During release what I do is I first release the
[BOM], then release the [PLATFORM] and up to here I see no problems. But
then I try to release the DEMO_STORE] and even though I specify on the
command line the version of the parent [BOM]:

-Ddependency.com.nemesis:bom.release=1.5.2.RELEASE
-Ddependency.com.nemesis:bom.development=1.5.3.BUILD-SNAPSHOT


it still asks me for versions of dependencies which are specified in the
released [BOM]. I tried patching the code and specifying a new version of
the parent

project.getParentArtifact().setVersion("1.5.2.RELEASE")

just to see if it works, but the problem is that the dependencies in the
project are already resolved: when I call project.getDependencies() I get
the SNAPSHOT versions.

Is there any way to reload the project model after I specify a new
parentVersion()? So that It understands the [BOM] is no longer a snapshot
version.

Thanks

2017-06-25 12:11 GMT+03:00 Robert Scholte <rfscho...@apache.org>:

> MRELEASE-362[1] is probably the matching issue.
> Be aware that some are talking about tagging every module. In most
> situations I don't like that. If the structure is hierarchical and the root
> is tagged, then all the modules are already tagged. All tags must be
> checked out during release:perform, keep that in mind.
> I see options with a flat structure and with the release-aggregator.
>
> Robert
>
> [1] https://issues.apache.org/jira/browse/MRELEASE-362
>
>
> On Sat, 24 Jun 2017 22:59:48 +0200, Petar Tahchiev <paranoia...@gmail.com>
> wrote:
>
> Hi Paul,
>>
>> I think you misunderstood. The [BOM] is a separate project and the
>> [PLATFORM] and [DEMO_STORE] are also separate projects, both of which
>> declare as their parent the [BOM].
>>
>> @Robert: I have added the test-case:
>> https://github.com/apache/maven-release/pull/18/commits/
>> Release-aggregator is exactly what's missing. Is there an issue I can
>> subscribe and track?
>>
>>
>> 2017-06-24 14:15 GMT+03:00 Robert Scholte <rfscho...@apache.org>:
>>
>> What we're still missing is a release-aggregator, which can release
>>> multiple release-roots at once. That would probably be the preferred fix,
>>> the suggested patch is just an easy work-around.
>>> It is still on my todo-list.
>>>
>>> Robert
>>>
>>>
>>> On Sat, 24 Jun 2017 12:42:22 +0200, Paul Hammant <p...@hammant.org>
>>> wrote:
>>>
>>> Easy to fix.  Have a profile 'platformOnly' in the root module (I'm not
>>>
>>>> sure if 'BOM' should mean anything to me) that includes only 'platform'
>>>> as
>>>> a child module.
>>>>
>>>>mvn release:prepare -PplatformOnly # etc
>>>>
>>>> Later when you're ready to do the demo store release, use another (from
>>>> root):
>>>>
>>>>mvn release:prepare -PdemoOnly # etc
>>>>
>>>> Of course, you man not need to stuff demo in your Artifactory/Nexus/etc
>>>> in
>>>> which case just do your deploy fu after an 'install' w/o the release
>>>> plugin
>>>> involved or that second profile.
>>>>
>>>> - Paul
>>>>
>>>>
>>>> On Sat, Jun 24, 2017 at 2:58 AM, Petar Tahchiev <paranoia...@gmail.com>
>>>> wrote:
>>>>
>>>> Hey guys,
>>>>
>>>>>
>>>>> I'm facing a number of challenges when I release the project at my
>>>>> company.
>>>>> Here's my setup:
>>>>>
>>>>> [BOM]
>>>>>  /\
>>>>>  [PLATFORM]  [DEMO_STORE]
>>>>>
>>>>> I have a master BOM project which holds all the version as defined
>>>>> properties. This BOM is the parent to two other projects - [PLATFORM]
>>>>> and
>>>>> [

Re: Maven release plugin

[Petar Tahchiev]

Hi Paul,

I think you misunderstood. The [BOM] is a separate project and the
[PLATFORM] and [DEMO_STORE] are also separate projects, both of which
declare as their parent the [BOM].

@Robert: I have added the test-case:
https://github.com/apache/maven-release/pull/18/commits/
Release-aggregator is exactly what's missing. Is there an issue I can
subscribe and track?


2017-06-24 14:15 GMT+03:00 Robert Scholte <rfscho...@apache.org>:

> What we're still missing is a release-aggregator, which can release
> multiple release-roots at once. That would probably be the preferred fix,
> the suggested patch is just an easy work-around.
> It is still on my todo-list.
>
> Robert
>
>
> On Sat, 24 Jun 2017 12:42:22 +0200, Paul Hammant <p...@hammant.org> wrote:
>
> Easy to fix.  Have a profile 'platformOnly' in the root module (I'm not
>> sure if 'BOM' should mean anything to me) that includes only 'platform' as
>> a child module.
>>
>>mvn release:prepare -PplatformOnly # etc
>>
>> Later when you're ready to do the demo store release, use another (from
>> root):
>>
>>mvn release:prepare -PdemoOnly # etc
>>
>> Of course, you man not need to stuff demo in your Artifactory/Nexus/etc in
>> which case just do your deploy fu after an 'install' w/o the release
>> plugin
>> involved or that second profile.
>>
>> - Paul
>>
>>
>> On Sat, Jun 24, 2017 at 2:58 AM, Petar Tahchiev <paranoia...@gmail.com>
>> wrote:
>>
>> Hey guys,
>>>
>>> I'm facing a number of challenges when I release the project at my
>>> company.
>>> Here's my setup:
>>>
>>> [BOM]
>>>  /\
>>>  [PLATFORM]  [DEMO_STORE]
>>>
>>> I have a master BOM project which holds all the version as defined
>>> properties. This BOM is the parent to two other projects - [PLATFORM] and
>>> [DEMO_STORE], The [PLATFORM] is a project with more than 60 modules
>>> inside,
>>> and the [DEMO_STORE] is a project that declares those modules as
>>> dependencies.
>>>
>>> Now what I want is to release all three from Jenkins. I can release the
>>> [BOM] with no problems, then I start release of the [PLATFORM] and all
>>> of a
>>> sudden Jenkins blocks because Maven asks me on the command line if I want
>>> to resolve the SNAPSHOT dependencies (remember the parent of the
>>> [PLATFORM]
>>> is the [BOM] SNAPSHOT version).
>>>
>>> So I created this issue https://issues.apache.org/jira
>>> /browse/MRELEASE-985
>>> to be able to specify the [BOM] parent version when I start the release
>>> of
>>> [PLATFORM]. I think I also fixed it with this pull-request:
>>> https://github.com/apache/maven-release/pull/18
>>>
>>> Can someone have a look at this pull request and tell me if it is OK?
>>>
>>> --
>>> 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
>
>


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

Maven release plugin

[Petar Tahchiev]

Hey guys,

I'm facing a number of challenges when I release the project at my company.
Here's my setup:

[BOM]
 /\
 [PLATFORM]  [DEMO_STORE]

I have a master BOM project which holds all the version as defined
properties. This BOM is the parent to two other projects - [PLATFORM] and
[DEMO_STORE], The [PLATFORM] is a project with more than 60 modules inside,
and the [DEMO_STORE] is a project that declares those modules as
dependencies.

Now what I want is to release all three from Jenkins. I can release the
[BOM] with no problems, then I start release of the [PLATFORM] and all of a
sudden Jenkins blocks because Maven asks me on the command line if I want
to resolve the SNAPSHOT dependencies (remember the parent of the [PLATFORM]
is the [BOM] SNAPSHOT version).

So I created this issue https://issues.apache.org/jira/browse/MRELEASE-985
to be able to specify the [BOM] parent version when I start the release of
[PLATFORM]. I think I also fixed it with this pull-request:
https://github.com/apache/maven-release/pull/18

Can someone have a look at this pull request and tell me if it is OK?

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

[Petar Tahchiev]

Hi Plamen,

thank you for your feedback. Indeed I had a look at the  XHTMLParser last
night and it seems that the macro calls are called inside it, during the
parsing of the template. And yes, that makes it impossible for the asciidoc
plugin to use these macros, because, as you said the asciidoctor plugin is
"cheating" by delegating the parsing to Asciidoctor itself.
To answer your question, I think the AsciidocParser extends the XHTMLParser
because this way it can only overwrite a single method - the `parse` method.

Thanks, Petar.

2017-06-13 23:54 GMT+03:00 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 
> 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 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 

Doxia Macros

[Petar Tahchiev]

Hey guys,

reading at this: https://maven.apache.org/doxia/macros/
==
Macros are currently only supported for APT, Xdoc and FML formats. Starting
with Doxia 1.7 (maven-site-plugin 3.5), macros are also supported for XHTML
and Markdown.
==
As I'm writing my documentation on Asciidoc and I'm using the
https://github.com/asciidoctor/asciidoctor-maven-plugin

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?

-- 
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: Release Apache Maven Archetype Plugin version 3.0.1

[Petar Tahchiev]

Hi Robert,

I tried testing it by adding this:


  staged-releases
  https://repository.apache.org/content/repositories/maven-1331



and this:


staged-releases
https://repository.apache.org/content/repositories/maven-1331


to one of my project's pom.xml and I tried to issue this command: mvn
archetype:create-from-project
-Darchetype.properties=src/main/resources/archetype.properties

but I get this error:

[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR]   The project
com.nemesis.archetype:samplestore-archetype:1.5.1.BUILD-SNAPSHOT
(/home/petar/workspace/nemesis-archetype/target/generated-sources/archetype/pom.xml)
has 2 errors
[ERROR] Unresolveable build extension: Plugin
org.apache.maven.archetype:archetype-packaging:3.0.1 or one of its
dependencies could not be resolved: Failed to read artifact descriptor for
org.apache.maven.archetype:archetype-packaging:jar:3.0.1: Failure to find
org.apache.maven.archetype:maven-archetype:pom:3.0.1 in
https://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced -> [Help 2]
[ERROR] Unknown packaging: maven-archetype @ line 8, column 14

And indeed the generated pom.xml
(/home/petar/workspace/nemesis-archetype/target/generated-sources/archetype/pom.xml)
contains the archetype extension:


  
org.apache.maven.archetype
archetype-packaging
3.0.1
  


but not the custom repository. After manually adding the pluginRepository
and successfully building the generated archetype I then created several
projects out of this archetype and it all seems to be good.

+1 from me.

2017-04-08 16:26 GMT+03:00 Robert Scholte :

> Hi,
>
> We solved 6 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> ctId=12317122=12339582=Text
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%
> 2012317122%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%
> 20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1331
> https://repository.apache.org/content/repositories/maven-133
> 1/org/apache/maven/archetype/maven-archetype/3.0.1/maven-
> archetype-3.0.1-source-release.zip
>
> Source release checksum(s):
> maven-archetype-3.0.1-source-release.zip sha1:
> 7332a5f891eb8ec128afa068ed669a9fa4420533
>
> Staging site:
> https://maven.apache.org/archetype-archives/archetype-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
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: Prepare Maven Archetype Plugin 3.0.1

[Petar Tahchiev]

Looks good to me - I've tested with my projects and it was OK.

2017-04-01 15:21 GMT+03:00 Robert Scholte :

> Hi,
>
> I've done some regression fixes for the Maven Archetype Plugin and want to
> do a release within a week.
> Would be nice if these fixes could be confirmed to prevent more negative
> reactions.
>
> thanks,
> Robert
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
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: SchemaExport adds engine=MyISAM to all create table statements.

[Petar Tahchiev]

Opps - wrong mailing list :(

Sorry for the spam :(

2017-04-02 15:58 GMT+03:00 Petar Tahchiev <paranoia...@gmail.com>:

> Hey guys,
>
> I've been using Hibernate's SchemaExport tool (5.1.x) for a long time it
> has always created an sql script with create-table statements like this:
>
> create table abstract_modifiable_entity (
> id bigint not null,
> code varchar(255) not null,
> created_by varchar(255),
> created_date datetime,
> last_modified_by varchar(255),
> last_modified_date datetime,
> primary key (id)
> );
>
> However now that I try to upgrade to the latest 5.2.x I see a change - it
> adds engine=MyISAM to the end of every create-table statement:
>
> create table abstract_modifiable_entity (
>id bigint not null,
> code varchar(255) not null,
> created_by varchar(255),
> created_date datetime,
> last_modified_by varchar(255),
> last_modified_date datetime,
> primary key (id)
> ) engine=MyISAM;
>
>
> Is this intentional or a bug? I tried to find something in the changelog
> but I couldn't. I even tried to declare the InnoDB dialect:
>
> spring.jpa.database-platform=org.hibernate.dialect.MySQL57InnoDBDialect
>
> but it still adds the MyISAM engine.
>
> Is there any API to set the required engine?
>
> Thank you.
>
>
> --
> 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
>



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

SchemaExport adds engine=MyISAM to all create table statements.

[Petar Tahchiev]

Hey guys,

I've been using Hibernate's SchemaExport tool (5.1.x) for a long time it
has always created an sql script with create-table statements like this:

create table abstract_modifiable_entity (
id bigint not null,
code varchar(255) not null,
created_by varchar(255),
created_date datetime,
last_modified_by varchar(255),
last_modified_date datetime,
primary key (id)
);

However now that I try to upgrade to the latest 5.2.x I see a change - it
adds engine=MyISAM to the end of every create-table statement:

create table abstract_modifiable_entity (
   id bigint not null,
code varchar(255) not null,
created_by varchar(255),
created_date datetime,
last_modified_by varchar(255),
last_modified_date datetime,
primary key (id)
) engine=MyISAM;


Is this intentional or a bug? I tried to find something in the changelog
but I couldn't. I even tried to declare the InnoDB dialect:

spring.jpa.database-platform=org.hibernate.dialect.MySQL57InnoDBDialect

but it still adds the MyISAM engine.

Is there any API to set the required engine?

Thank you.


-- 
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: [VOTE] Release Apache Maven 3.5.0-alpha-1

[Petar Tahchiev]

+1

I've been testing today with our projects and it all looks good.

2017-02-24 16:59 GMT+02:00 Petr Široký :

> Hello,
>
> I've tested the 3.5.0-alpha-1 with several quite large projects (hundreds
> of modules in total) and everything looks good.
>
> +1 non-binding (hopefully I understood correctly I can do that)
>
> Petr
>
> On Fri, Feb 24, 2017 at 11:13 AM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > https://issues.apache.org/jira/browse/MNG-6178 created
> >
> > On 23 February 2017 at 21:56, Christian Schulte  wrote:
> >
> > > Can we have this patch included? I wanted to commit this to master
> > > yesterday when the build job succeeded. This is just pending the
> Jenkins
> > > update to get the job succeed. I would just merge it to master now.
> > >
> > >  > > shortlog;h=refs/heads/MNG-5889>
> > >
> > >  > > 37b5f27080006883613800127d70e8233210555e>
> > >
> > > So that we do not need to re-open MNG-5889 or even create a new issue.
> > > Otherwise
> > >
> > > +1
> > >
> > > No objections to get a release out.
> > >
> > > Regards,
> > > --
> > > Christian
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>



-- 
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: Injecting MavenProject

[Petar Tahchiev]

Hey guys,

thank you for the fast response. I ended up using:

@Inject
protected Provider mavenProjectProvider;

Which works perfectly fine.

Thank you.


2017-02-22 9:12 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>:

> IIUC, this feature is available since Maven 3.2.1 (MNG-5530)
>
> Regards,
>
> Hervé
>
> Le mardi 21 février 2017, 22:54:41 CET Igor Fedorenko a écrit :
> > MavenProject is injected as a MojoExecutionScope'd component (see
> > DefaultBuildPluginManager around line 119). Since old-style Plexus
> > components are singleton's by default, there is only one
> > AsciidoctorParser instance which holds the first MavenProject it was
> > used with for the entire build.
> >
> > Couple of ways to solve this.
> >
> > If AsciidoctorParser instances are cheap to create and are disposable,
> > then the easiest solution is to make AsciidoctorParser as non-singleton
> > (this is the default for jsr330 components, and for plexus @Component
> > use instantiationStrategy = "per-lookup").
> >
> > If AsciidoctorParser must be a singleton, then you need to use
> > javax.inject.Provider to access current context MavenProject instance.
> >
> > Hope this helps.
> >
> > > ie. see line 61 of the maven-plugin-tools annotations reference
> > > documentation
> > >
> > > http://maven.apache.org/plugin-tools/maven-plugin-tools-annotations/
> > > index.html#Supported_Annotations
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le mardi 21 février 2017, 19:47:05 CET Robert Scholte a écrit :
> > > > On Tue, 21 Feb 2017 16:16:55 +0100, Petar Tahchiev
> > > > <paranoia...@gmail.com>
> > > >
> > > > wrote:
> > > > > Hello guys,
> > > > >
> > > > > I've recently found out something weird while working with the
> > > > > asciidoctor
> > > > > maven plugin.My project has the following structure:
> > > > >
> > > > > PARENT:
> > > > >  - MODULEA
> > > > >  - MODULEB
> > > > >  - MODULEC
> > > > >
> > > > > and the asciidoctor team have created this doxia parser to be able
> to
> > > > > render asciidoc content as part of your maven site:
> > > > >
> > > > > https://github.com/asciidoctor/asciidoctor-maven-
> plugin/blob/master/sr
> > > > > c/ma
> > > > > in/java/org/asciidoctor/maven/site/AsciidoctorParser.java#L53>
> > > > >
> > > > > Note that they are injecting the MavenProject like this:
> > > > > @Requirement
> > > > > protected MavenProject project;
> > > > >
> > > > > and when I run the site generation at the PARENT (mvn clean site)
> this
> > > > > parser gets called 4 times, and all the 4 times the MavenProject
> that
> > > > > gets
> > > > > injected is PARENT.
> > > > >
> > > > > However, if I run the site generation at PARENT but tell it to
> resume
> > > > > from
> > > > > MODULEA:
> > > > >
> > > > > mvn clean site -rf :MODULEA
> > > > >
> > > > > then the MavenProject is MODULEA every time. First time it is
> MODULEA,
> > > > > second time it is MODULEA and third time it is MODULEA.
> > > > >
> > > > > This may seem like a very small difference, but if you use
> properties
> > > > > like
> > > > > ${project.build.directory} then suddenly your site and images are
> > > > > generated
> > > > > in wrong folders.
> > > > >
> > > > > My questions is:
> > > > >   1) Does it look like a bug in Maven reactor? Or perhaps plexus?
> > > >
> > > > MavenProject is not something which should work like this. It would
> mean
> > > > that project is a @Named component (JSR330), which it isn't. So I
> think
> > > > that it leaks to the plexus context, which shouldn't happen, but
> might
> > > > explain why you always get the same instance.
> > > > A MavenProject is something which needs to be passed as an argument.
> > > >
> > > > Robert
> > > >
> > > > >   2) Is there any special way that I can inject the current child
> > > > >   module

Injecting MavenProject

[Petar Tahchiev]

Hello guys,

I've recently found out something weird while working with the asciidoctor
maven plugin.My project has the following structure:

PARENT:
 - MODULEA
 - MODULEB
 - MODULEC

and the asciidoctor team have created this doxia parser to be able to
render asciidoc content as part of your maven site:

https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/master/src/main/java/org/asciidoctor/maven/site/AsciidoctorParser.java#L53

Note that they are injecting the MavenProject like this:

@Requirement
protected MavenProject project;

and when I run the site generation at the PARENT (mvn clean site) this
parser gets called 4 times, and all the 4 times the MavenProject that gets
injected is PARENT.

However, if I run the site generation at PARENT but tell it to resume from
MODULEA:

mvn clean site -rf :MODULEA

then the MavenProject is MODULEA every time. First time it is MODULEA,
second time it is MODULEA and third time it is MODULEA.

This may seem like a very small difference, but if you use properties like
${project.build.directory} then suddenly your site and images are generated
in wrong folders.

My questions is:
  1) Does it look like a bug in Maven reactor? Or perhaps plexus?
  2) Is there any special way that I can inject the current child module of
the mulit-module build. I want the MavenProject that is injected to be
first time MODULEA, second time MODULEB and third time MODULEC.

Regarding point 2 I saw Anders had the same question here:

http://maven.40175.n5.nabble.com/Get-hold-of-MavenProject-object-of-a-module-in-a-multi-module-build-td5811486.html

but I didn't get the answer.

Thank you.

-- 
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: Possible bug in Maven-core

[Petar Tahchiev]

Hi Robert,

this:


AFAIK we're never creating a new ProjectBuildingRequest, we should be using
the original or a clone of it, so the suggestion to set both types of
properties seems weird.

is not true:

https://github.com/apache/maven-archetype/blob/master/archetype-common/src/main/java/org/apache/maven/archetype/creator/FilesetArchetypeCreator.java#L435

You can clearly see that if the project.getParent() != null a new
DefaultProjectBuildingRequest(); is created and that new request is missing
the system properties and the user-specified properties.

As suggested I have opened a ticket here:
https://issues.apache.org/jira/browse/ARCHETYPE-518

Also, again, as suggested I have just committed a test-case inside
DefaultArchetypeCreatorIT#testSystemPropertiesAreIncluded

At the moment that test fails with null-pointer exception because the
archetype is using maven-core version 3.0 for its tests.

I've tested with both - with latest maven 3.5.x-SNAPSHOT - I get a
different kind of error
  - with maven 3.0.4 i get the exact same
null-pointer as the test suggests.


Finally I have also committed 2 lines inside FilesetArchetypeCreator to
resolve the issue:

//buildingRequest.setSystemProperties(
System.getProperties() );
//buildingRequest.setUserProperties(
configurationProperties );

Please let me know if you are OK with this.

Thank you.


2017-02-13 20:54 GMT+02:00 Robert Scholte <rfscho...@apache.org>:

> Hi Peter,
>
> I would consider this as a Maven Archetype issue.
> Regarding the properties, the MavenSession has a deprecated method
> getExecutionProperties(), which is split up into getSystemProperties() and
> getUserProperties(). When using the Invoker it doesn't make sense to add
> SystemProperties (again), userProperties (-Dkey=value entries) should be
> enough. But it could be I missed a usecase, which also implies there are
> not enough integration tests.
>
> AFAIK we're never creating a new ProjectBuildingRequest, we should be
> using the original or a clone of it, so the suggestion to set both types of
> properties seems weird.
>
> If you can create a JIRA issue for ARCHETYPE with a small integration test
> for the plugin, it shouldn't be so hard to fix it.
>
> thanks,
> Robert
>
> On Mon, 13 Feb 2017 16:35:18 +0100, Petar Tahchiev <paranoia...@gmail.com>
> wrote:
>
> Hi guys,
>>
>> I'm writing here to ask what I have found is a bug or not. I have a
>> project
>> and I want to create an archetype out of it. So I use the following
>> command:
>>
>> mvn archetype:create-from-project
>> -Darchetype.properties=src/main/resources/archetype.properties
>>
>> It used to work fine with maven-archetype<=2.4 but now with 3.0 it fails
>> with:
>>
>> Caused by: org.apache.maven.plugin.MojoFailureException: Error reading
>> parent POM of project: com.nemesis:bom:1.5.0.BUILD-SNAPSHOT
>> at
>> org.apache.maven.archetype.mojos.CreateArchetypeFromProjectM
>> ojo.execute(CreateArchetypeFromProjectMojo.java:269)
>> at
>> org.apache.maven.plugin.DefaultBuildPluginManager.executeMoj
>> o(DefaultBuildPluginManager.java:134)
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
>> oExecutor.java:207)
>>
>> I started debugging and I found out that the problem is in this commit:
>>
>> https://github.com/apache/maven-archetype/commit/624f9affdc2
>> 7c8efe6443e03e89259dbe51d08dd
>>
>> which migrates the plugin to Maven3.
>>
>> Furthermore debugging and stacktrace analysis revealed this:
>>
>>
>> *[ERROR] Failed to determine Java version for profile
>> doclint-java8-disable
>> @ org.jboss:jboss-parent:19,
>> /home/petar/.m2/repository/org/jboss/jboss-parent/19/jboss-parent-19.pom,
>> line 746, column 15*
>> and indeed inside my parent pom.xml I have included the jboss bom like
>> this:
>>
>> 
>> org.drools
>> drools-bom
>> pom
>> ${drools.version}
>> import
>> 
>>
>> which has a parent the jboss-parent.
>>
>> Now if you debug further more in the maven-archetype-plugin you will see
>> here:
>>
>> https://github.com/apache/maven-archetype/blob/master/archet
>> ype-common/src/main/java/org/apache/maven/archetype/
>> creator/FilesetArchetypeCreator.java#L439
>>
>> we create a new DefaultProjectBuildingRequest and don't set any system
>> properties to it
>> so it eventually gets passed down to maven-core which cannot find
>> "java.version"
>> 

Possible bug in Maven-core

[Petar Tahchiev]

Hi guys,

I'm writing here to ask what I have found is a bug or not. I have a project
and I want to create an archetype out of it. So I use the following command:

mvn archetype:create-from-project
-Darchetype.properties=src/main/resources/archetype.properties

It used to work fine with maven-archetype<=2.4 but now with 3.0 it fails
with:

Caused by: org.apache.maven.plugin.MojoFailureException: Error reading
parent POM of project: com.nemesis:bom:1.5.0.BUILD-SNAPSHOT
at
org.apache.maven.archetype.mojos.CreateArchetypeFromProjectMojo.execute(CreateArchetypeFromProjectMojo.java:269)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)

I started debugging and I found out that the problem is in this commit:

https://github.com/apache/maven-archetype/commit/624f9affdc27c8efe6443e03e89259dbe51d08dd

which migrates the plugin to Maven3.

Furthermore debugging and stacktrace analysis revealed this:


*[ERROR] Failed to determine Java version for profile doclint-java8-disable
@ org.jboss:jboss-parent:19,
/home/petar/.m2/repository/org/jboss/jboss-parent/19/jboss-parent-19.pom,
line 746, column 15*
and indeed inside my parent pom.xml I have included the jboss bom like this:


org.drools
drools-bom
pom
${drools.version}
import


which has a parent the jboss-parent.

Now if you debug further more in the maven-archetype-plugin you will see
here:

https://github.com/apache/maven-archetype/blob/master/archetype-common/src/main/java/org/apache/maven/archetype/creator/FilesetArchetypeCreator.java#L439

we create a new DefaultProjectBuildingRequest and don't set any system
properties to it
so it eventually gets passed down to maven-core which cannot find
"java.version"
system property (because there are no properties passed) and it adds the
error that I see.

Now I have a several questions: why have we left the ProjectBuildingRequest
without system properties? Also the ProjectBuildingRequest has no
userProperties set - is this OK? I can fix the system properties with:

buildingRequest.setSystemProperties( System.getProperties() );
buildingRequest.setUserProperties( configurationProperties );

but is this correct?


-- 
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: Plexus Component Injection

[Petar Tahchiev]

Hi Robert,

thank you for your reply. I tried searching for maven-artifact-transfer in
the central, but i couldn't find it:

http://search.maven.org/#search%7Cga%7C1%7Cmaven-artifact-transfer

I also tried in google and I got this page:

https://maven.apache.org/shared-archives/maven-artifact-transfer-LATEST/dependency-info.html

but there is no such artifact in org.apache.maven.shared

Are you referring to ArtifactResolver in org.apache.maven:maven-artifact?

We are using it already - our DefaultDownloader is injecting it as I
pointed above, but it is missing the proxy settings.


2016-06-29 19:40 GMT+02:00 Robert Scholte <rfscho...@apache.org>:

> Wagon[1] is only about transportation and it not aware of any Maven
> configuration such as the settings.xml, hence there are no Maven core
> dependencies
>
> I don't think you need the DefaultDownloader. Instead I would try to use
> the ArtifactResolver from maven-artifact-transfer, which *is* aware of
> Maven configuration.
>
> Give it a try to rewrite it. Let me know if you need extra hints to
> refactor this.
>
> thanks,
> Robert
>
> [1] http://maven.apache.org/components/wagon/
>
>
> On Wed, 29 Jun 2016 10:26:44 +0200, Petar Tahchiev <paranoia...@gmail.com>
> wrote:
>
> Hello guys,
>>
>> I'm running the tests in maven-archetype with Windows and a proxy (yeah, I
>> know :)) and one of them fails because it cannot find an archetype with
>> the
>> archetype manager. So I looked at the DefaultDownloader in
>> archetype-common
>> which injects ArtifactResolver like this:
>>
>> @Requirement
>> private ArtifactResolver artifactResolver;
>>
>> and when I stop with a breakpoint to inspect the artifact resolver, I see
>> it is of type DefaultArchetypeResolver and the WagonManager inside it has
>> an empty map of proxies defined. This however contradicts to my
>> settings.xml:
>>
>> 
>>
>>aproxy
>>true
>>http
>>
>>
>>
>>
>>localhost
>>
>> 
>>
>> Any idea who's defining the artifactResolver or why it does not respect my
>> settings.xml when running a test?
>>
>> P.S. The build was failing because it couldn't download the dependencies,
>> but then I declared the proxy and that went fine. So it looks like the
>> proxy works fine when downloading dependencies, but not when I run the
>> tests.
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


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

Plexus Component Injection

[Petar Tahchiev]

Hello guys,

I'm running the tests in maven-archetype with Windows and a proxy (yeah, I
know :)) and one of them fails because it cannot find an archetype with the
archetype manager. So I looked at the DefaultDownloader in archetype-common
which injects ArtifactResolver like this:

@Requirement
private ArtifactResolver artifactResolver;

and when I stop with a breakpoint to inspect the artifact resolver, I see
it is of type DefaultArchetypeResolver and the WagonManager inside it has
an empty map of proxies defined. This however contradicts to my
settings.xml:


   
   aproxy
   true
   http
   
   
   
   
   localhost
   


Any idea who's defining the artifactResolver or why it does not respect my
settings.xml when running a test?

P.S. The build was failing because it couldn't download the dependencies,
but then I declared the proxy and that went fine. So it looks like the
proxy works fine when downloading dependencies, but not when I run the
tests.

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

MNG-5916: Allow filtering out certain loggers from within a plugin

[Petar Tahchiev]

Hello,

I recently got into a problem with my custom plugin. I want to filter out
some loggers, only for my plugin execution and I realized this is not
possible at the moment. I found out this issue which states exactly the
same:

https://issues.apache.org/jira/browse/MNG-5916

The bottleneck for me seems to be the slf4j. SLF4J does not allow you to
change at runtime the log levels, as stated here:

http://stackoverflow.com/questions/14544991/how-to-configure-slf4j-simple

I actually tried putting this in my Mojo:

System.setProperty(org.slf4j.impl.SimpleLogger.DEFAULT_LOG_LEVEL_KEY, "WARN");

but it had no effect because the logger had already been created.

If, on the other hand, they did allow the runtime switch of the log levels
then we could have a method (for example reconfigure()) in the
AbstractMojo's log object, like this:

@Override
public void execute() throws MojoExecutionException, MojoFailureException {

   Map config = new HashMap<>();

   config.put("org.slf4j.simpleLogger.defaultLogLevel", "WARN");

   getLog().reconfigure(config);

}

and so each Mojo could reconfigure the log before it's own execution. This
is very rough, but I hope you get it. I'm also far from the idea to switch
the log level API, but is there any particular reason we're sticking with
SLF4J's SimpleLogger? I know Log4J2 and Logback provide the ability to
change the log levels at runtime. And I also don't think performance-wise
they are a lot worse than SLF4J (considering the amount of log a typical
maven execution produces).

I would be interested to hear your opinion.

-- 
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: colorized Maven output

[Petar Tahchiev]

Hello,

I checked on Windows with Herve's [1]. Unfortunately I am unable to build
my project with 3.4.0-SNAPSHOT. I have this dependency:


org.drools
drools-bom
pom
${drools.version}
import


where drools version is defined to be
6.4.0.Final. And when I build it I get:

[ERROR] Non-resolvable import POM: Failure to find
org.kie:kie-bom:pom:${project.version} in http://repo1.maven.org/maven2/
was cached in the local repository, resolution will not be reattempted
until the update interval of official-m2-repo has elapsed or updates are
forced @ org.drools:drools-bom:[unknown-version]
[org.drools:drools-bom:[unknown-version]],
[C:\Users\e-tahchpet\.m2\repository\org\drools\drools-bom\6.4.0.Final\drools-bom-6.4.0.Final.pom],
line 27, column 19

If I comment this dependency then I see some colors on windows, but at the
end of the build findbugs will break:

[ERROR] Failed to execute goal
org.codehaus.mojo:findbugs-maven-plugin:3.0.1:findbugs (findbugs) on
project bom: Unable to parse configuration of mojo
org.codehaus.mojo:findbugs-maven-plugin:3.0.1:findbugs for parameter
pluginArtifacts: Cannot assign configuration entry 'pluginArtifacts' with
value '${plugin.artifacts}' of type
java.util.Collections.UnmodifiableRandomAccessList to property of type
java.util.ArrayList -> [Help 1]

BTW, my opinion is that this colorized output is a great feature, but we're
missing on some more important stuff - for example at the moment changing
the log level per plugin is not possible. I'm writing a custom maven plugin
which uses flyway and flyway produces a lot of output noise that I want to
get rid of, but I am unable to, because flyway uses SLF4J, and because
maven provides simple logger, flyway in my maven plugin uses the simple
logger from maven. And the only way to change the simple logger level is to
the tell the client to change his values in simplelogger.properties file in
his $MAVEN_HOME which is really unacceptable. It would be great if any
maven plugin can control the log level output.


2016-06-09 8:30 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>:

> You can download a binary build from Jenkins [1] that works for me even on
> Windows
>
> I created 2 jobs:
> - one in forked mode, that works [2]
> - one in embedded mode, which shows 14 errors & 29 failures [3]
>
> I don't know why embedded mode fails: still need to investigate.
> But as forked mode shows, as a normal user, this branch should work
> perfectly.
>
> Feedback appreciated, both on embedded failures investigation and on normal
> use of the build.
>
> Regards,
>
> Hervé
>
> [1]
> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-embedded-MNG-3507-color/ws/maven-3-trunk/apache-maven/target/
>
> [2]
> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-jdk-1.7-MNG-3507-color/2/console
>
> [3]
> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-embedded-MNG-3507-color/1/console
>
>
> Le mardi 7 juin 2016 00:41:11 Hervé BOUTEMY a écrit :
> > I tried on Windows: it does not work yet
> >
> > Th eissue I'm facing is: we need to call AnsiConsole.systemInstall() for
> > Windows
> > But if this call is added in MavenCli.doMain(), core ITs fail since
> there is
> > confusion on System.out replacements...
> >
> > I still didn't find any way to avoid this confusion: if somebody has an
> > idea...
> >
> > Regards,
> >
> > Hervé
> >
> > Le lundi 6 juin 2016 16:15:48 Petar Tahchiev a écrit :
> > > Sorry, I got confused by this: "if run with older Maven, color is
> always
> > > on".
> > >
> > > I will try it later.
> > >
> > > 2016-06-06 15:46 GMT+02:00 Tamás Cservenák <ta...@cservenak.net>:
> > > > I believe you need to build Maven itself from Herve's branch:
> > > > https://github.com/apache/maven/tree/MNG-3507
> > > >
> > > > On Mon, Jun 6, 2016 at 3:14 PM Petar Tahchiev <paranoia...@gmail.com
> >
> > > >
> > > > wrote:
> > > > > I might be doing smth wrong but I tested on windows 10 with Maven
> > > > > 3.3.9
> > > >
> > > > and
> > > >
> > > > > I didn't see any color.  Here's what I did:
> > > > >
> > > > > 1) git clone g...@github.com:apache/maven-shared.git
> > > > > 2) cd maven-share/ && mvn clean install
> > > > > 3) git clone g...@github.com:apache/maven-integration-testing.git
> > > > > 4) cd maven-integration-testing && mvn clean install
> > &

Re: colorized Maven output

[Petar Tahchiev]

Sorry, I got confused by this: "if run with older Maven, color is always
on".

I will try it later.

2016-06-06 15:46 GMT+02:00 Tamás Cservenák <ta...@cservenak.net>:

> I believe you need to build Maven itself from Herve's branch:
> https://github.com/apache/maven/tree/MNG-3507
>
> On Mon, Jun 6, 2016 at 3:14 PM Petar Tahchiev <paranoia...@gmail.com>
> wrote:
>
> > I might be doing smth wrong but I tested on windows 10 with Maven 3.3.9
> and
> > I didn't see any color.  Here's what I did:
> >
> > 1) git clone g...@github.com:apache/maven-shared.git
> > 2) cd maven-share/ && mvn clean install
> > 3) git clone g...@github.com:apache/maven-integration-testing.git
> > 4) cd maven-integration-testing && mvn clean install
> >
> > I also tried to build only that particular module too:
> > 5) cd maven-integration-testing\core-it-support\maven-it-helper\ && mvn
> > clean install
> >
> > The result is
> >
> > ---
> >  T E S T S
> > ---
> > Running org.apache.maven.it.MavenIntegrationTestCaseTest
> > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.425
> sec -
> > in org.apache.maven.it.MavenIntegrationTestCaseTest
> >
> > Results :
> >
> > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
> >
> > [INFO]
> > [INFO] --- maven-jar-plugin:2.5:jar (default-jar) @ maven-it-helper ---
> > [INFO] Building jar:
> >
> >
> C:\workspace\maven-integration-testing\core-it-support\maven-it-helper\target\maven-it-helper-2.1-SNAPSHOT.jar
> >
> > and no color.
> >
> > 2016-06-06 14:31 GMT+02:00 jieryn <jie...@gmail.com>:
> >
> > > Also, to get Jenkins displaying ANSI escape codes for color you can
> > > install https://wiki.jenkins-ci.org/display/JENKINS/AnsiColor+Plugin
> > > and then enable it per-job.
> > >
> > > On Mon, Jun 6, 2016 at 2:33 AM, Romain Manni-Bucau
> > > <rmannibu...@gmail.com> wrote:
> > > > Hi Hervé,
> > > >
> > > > would it be possible to enhance this with such features:
> > > >
> > > > 1. make colors configurables through a user config
> (~/.m2/settings.xml?
> > > or
> > > > colors.xml)
> > > > 2. make color config regex friendly. The idea is to be able to get a
> > > > coloration like https://github.com/rmannibucau/maven-color which
> > depends
> > > > what is shown and not only the level
> > > >
> > > > ?
> > > >
> > > > Anyway thanks for moving forward this feature expected for too long
> by
> > a
> > > > LOT of users!
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > <http://www.tomitribe.com> | JavaEE Factory
> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >
> > > > 2016-06-06 8:26 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>:
> > > >
> > > >> Hi,
> > > >>
> > > >> As you may have noticed, I created a MNG-3507 branch.
> > > >> The idea here is to develop colorization not at slf4j implementation
> > > level,
> > > >> but in core (and later plugins): slf4j implementation is only
> > > responsible
> > > >> for
> > > >> DEBUG/INFO/WARNING/ERROR colorization, core and plugins are
> > responsible
> > > for
> > > >> messages.
> > > >>
> > > >> I implemented message colorization that J Dillon did in
> slf4j-gossip:
> > > the
> > > >> only
> > > >> part I still didn't do is the stacktrace enhancement.
> > > >> Batch mode disables color: we can choose to create specific CLI
> > options
> > > >> later
> > > >> if we prefer.
> > > >> And the most important is that core provides jansi to plugins: any
> > > plugin
> > > >> using jansi benefits from jansi configuration (mainly enable/disable
> > > color)
> > > >>
> > > >> As a proof of concept, I implemented color output in core ITs
> invoker
> > > [1]:
&

Re: colorized Maven output

[Petar Tahchiev]

I might be doing smth wrong but I tested on windows 10 with Maven 3.3.9 and
I didn't see any color.  Here's what I did:

1) git clone g...@github.com:apache/maven-shared.git
2) cd maven-share/ && mvn clean install
3) git clone g...@github.com:apache/maven-integration-testing.git
4) cd maven-integration-testing && mvn clean install

I also tried to build only that particular module too:
5) cd maven-integration-testing\core-it-support\maven-it-helper\ && mvn
clean install

The result is

---
 T E S T S
---
Running org.apache.maven.it.MavenIntegrationTestCaseTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.425 sec -
in org.apache.maven.it.MavenIntegrationTestCaseTest

Results :

Tests run: 2, Failures: 0, Errors: 0, Skipped: 0

[INFO]
[INFO] --- maven-jar-plugin:2.5:jar (default-jar) @ maven-it-helper ---
[INFO] Building jar:
C:\workspace\maven-integration-testing\core-it-support\maven-it-helper\target\maven-it-helper-2.1-SNAPSHOT.jar

and no color.

2016-06-06 14:31 GMT+02:00 jieryn :

> Also, to get Jenkins displaying ANSI escape codes for color you can
> install https://wiki.jenkins-ci.org/display/JENKINS/AnsiColor+Plugin
> and then enable it per-job.
>
> On Mon, Jun 6, 2016 at 2:33 AM, Romain Manni-Bucau
>  wrote:
> > Hi Hervé,
> >
> > would it be possible to enhance this with such features:
> >
> > 1. make colors configurables through a user config (~/.m2/settings.xml?
> or
> > colors.xml)
> > 2. make color config regex friendly. The idea is to be able to get a
> > coloration like https://github.com/rmannibucau/maven-color which depends
> > what is shown and not only the level
> >
> > ?
> >
> > Anyway thanks for moving forward this feature expected for too long by a
> > LOT of users!
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Tomitriber
> >  | JavaEE Factory
> > 
> >
> > 2016-06-06 8:26 GMT+02:00 Hervé BOUTEMY :
> >
> >> Hi,
> >>
> >> As you may have noticed, I created a MNG-3507 branch.
> >> The idea here is to develop colorization not at slf4j implementation
> level,
> >> but in core (and later plugins): slf4j implementation is only
> responsible
> >> for
> >> DEBUG/INFO/WARNING/ERROR colorization, core and plugins are responsible
> for
> >> messages.
> >>
> >> I implemented message colorization that J Dillon did in slf4j-gossip:
> the
> >> only
> >> part I still didn't do is the stacktrace enhancement.
> >> Batch mode disables color: we can choose to create specific CLI options
> >> later
> >> if we prefer.
> >> And the most important is that core provides jansi to plugins: any
> plugin
> >> using jansi benefits from jansi configuration (mainly enable/disable
> color)
> >>
> >> As a proof of concept, I implemented color output in core ITs invoker
> [1]:
> >> if
> >> run with older Maven, color is always on (since core doesn't provide
> >> configured jansi), but if run with the branch, the plugin has color
> >> deactivated in batch mode.
> >> As you can see, also, Jenkins doesn't display ansi code nicely [2]...
> >>
> >> I also updated some IT test code to strip ansi codes [3] and not choke
> with
> >> color on.
> >>
> >> I still need to test on Windows, if nobody beats me at it.
> >>
> >> If nobody objects, I'll merge code to master and update slf4j-gossip
> >> accordingly (a lot of features are now in core): the discussion on
> changing
> >> default slf4j implementation will happen a little bit later.
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >>
> >> [1]
> >>
> http://git-wip-us.apache.org/repos/asf/maven-integration-testing/commit/13bd5416
> >>
> >> [2]
> >>
> https://builds.apache.org/view/M-R/view/Maven/job/core-integration-testing-maven-3-embedded/7280/console
> >>
> >> [3] http://svn.apache.org/r1746888
> >>
> >> -
> >> 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
>
>


-- 
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: [VOTE] Release Apache Maven Shared Component: Maven Shared Utils 3.0.1

[Petar Tahchiev]

+1 (non-PMC)

2016-06-01 22:11 GMT+03:00 Karl Heinz Marbaise :

> Hi,
>
> ony more PMC Vote needed ;-).
>
>
> Kind regards
> Karl Heinz
> On 5/29/16 12:23 AM, Karl Heinz Marbaise wrote:
>
>> Hi,
>>
>> We have solved 5 issues:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20fixVersion%20%3D%20maven-shared-utils-3.0.1
>>
>>
>> There are still a couple of issues left in JIRA:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20component%20%3D%20maven-shared-utils%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
>>
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1270
>>
>> https://repository.apache.org/content/repositories/maven-1270/org/apache/maven/shared/maven-shared-utils/3.0.1/maven-shared-utils-3.0.1-source-release.zip
>>
>>
>> Source release checksum(s):
>> maven-shared-utils-3.0.1-source-release.zip sha1:
>> 99c27693d8aa5e3c62f8ee60e668f570573eafb9
>>
>> Staging site:
>>
>> http://maven.apache.org/shared-archives/maven-shared-utils-LATEST/taglist.html
>>
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
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: Maven Release Plugin And A BOM

[Petar Tahchiev]

Yeah,

I guess I feel the same and that's why I wanted to consult the dev list
first before raising a JIRA.

2016-05-03 23:21 GMT+02:00 Jörg Schaible <joerg.schai...@gmx.de>:

> Hi Petar,
>
> Petar Tahchiev wrote:
>
> > Hi all,
> >
> > @Uwe - the enforcer rules are great, but I don't think I need them.
> > @Jorg - Resolving the parent during release:prepare is fine. What I don't
> > like is that it also asks me to resolve the platform version.
>
> The point is, that Maven does not recreate the effective POM to build again
> the list of versions to resolve. It's simply a corner case. Some might
> argue
> it is undefined behavior, others might say it's a bug ;-)
>
> Cheers,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
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: Maven Release Plugin And A BOM

[Petar Tahchiev]

Hi all,

@Uwe - the enforcer rules are great, but I don't think I need them.
@Jorg - Resolving the parent during release:prepare is fine. What I don't
like is that it also asks me to resolve the platform version.

I'll go with Robert's suggestion.

2016-05-03 19:51 GMT+03:00 Jörg Schaible <joerg.schai...@gmx.de>:

> Petar Tahchiev wrote:
>
> > Hi guys,
> >
> > I have a question regarding the release plugin. In my project I have a
> BOM
> > in which I declare a property and a dependencyManagement section:
> >
> > com.mycompany
> > my-bom
> > 1.0-SNAPSHOT
> >
> > 
> > 1.0-SNAPSHOT
> > 
> >
> > 
> >
> >   com.mycompany
> >   platform
> >   ${platform.version}
> >   
> > 
> >
> >
> > and I also have 3 different projects that declare this BOM as their
> > parent. All of these projects have the same version number (1.0-SNAPSHOT)
> > and when I make a release I always release all of them. This is how it
> > looks like: 1) I change platform.version property to 1.0, commit, push
> and
> > release the bom.
> > 2) I try to release first of my other projects and now the release plugin
> > is asking me to resolve the version of the BOM. Ok, fair enough, I
> resolve
> > it to 1.0 but then it asks me again to resolve the version of
> > com.mycompany:platform. This clearly is a bug right? I have changed it to
> > 1.0 before so it is no longer a SNAPSHOT???
> > If you think this is a problem, I will submit it in the JIRA and try to
> > fix it. I'm just not sure if it's a bug or maybe it's a known issue, or
> > maybe that's how it is supposed to be.
>
> You mean, you let the release plugin resolve the parent? We always manually
> "resolved" the parent first...
>
> Cheers,
> Jörg
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
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: Maven Release Plugin And A BOM

[Petar Tahchiev]

Hi Robert,

thank you for your comment. The idea behind the property was that I also
give the BOM to my clients and they declare it as their parent. So now if
they want to use a newer version of the platform, all they have to do
is redeclare the property  to be 1.2 or 1.5 or whatever
they want. Otherwise they will have to re-declare the whole dependency.

Now that I think about it I was wrong - if my clients want to update the
platform version all they have to do is update version of the parent BOM.

I still think though that this is a bug.


2016-05-03 16:17 GMT+02:00 Robert Patrick <robert.patr...@oracle.com>:

> Why bother with the custom property?  Do this instead and the release
> plugin is happy:
>
> com.mycompany
> my-bom
> 1.0-SNAPSHOT
>
> 
>
>   com.mycompany
>   platform
>   ${project.version}
>   
> 
>
>
>
> -Original Message-
> From: Petar Tahchiev [mailto:paranoia...@gmail.com]
> Sent: Tuesday, May 03, 2016 9:10 AM
> To: Maven Developers List
> Subject: Maven Release Plugin And A BOM
>
> Hi guys,
>
> I have a question regarding the release plugin. In my project I have a BOM
> in which I declare a property and a dependencyManagement section:
>
> com.mycompany
> my-bom
> 1.0-SNAPSHOT
>
> 
> 1.0-SNAPSHOT
> 
>
> 
>
>   com.mycompany
>   platform
>   ${platform.version}
>   
> 
>
>
> and I also have 3 different projects that declare this BOM as their parent.
> All of these projects have the same version number (1.0-SNAPSHOT) and when
> I make a release I always release all of them. This is how it looks like:
> 1) I change platform.version property to 1.0, commit, push and release the
> bom.
> 2) I try to release first of my other projects and now the release plugin
> is asking me to resolve the version of the BOM. Ok, fair enough, I resolve
> it to 1.0 but then it asks me again to resolve the version of
> com.mycompany:platform. This clearly is a bug right? I have changed it to
> 1.0 before so it is no longer a SNAPSHOT???
> If you think this is a problem, I will submit it in the JIRA and try to
> fix it. I'm just not sure if it's a bug or maybe it's a known issue, or
> maybe that's how it is supposed to be.
>
> --
> 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
>
>


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

Maven Release Plugin And A BOM

[Petar Tahchiev]

Hi guys,

I have a question regarding the release plugin. In my project I have a BOM
in which I declare a property and a dependencyManagement section:

com.mycompany
my-bom
1.0-SNAPSHOT


1.0-SNAPSHOT



   
  com.mycompany
  platform
  ${platform.version}
  



and I also have 3 different projects that declare this BOM as their parent.
All of these projects have the same version number (1.0-SNAPSHOT) and when
I make a release I always release all of them. This is how it looks like:
1) I change platform.version property to 1.0, commit, push and release the
bom.
2) I try to release first of my other projects and now the release plugin
is asking me to resolve the version of the BOM. Ok, fair enough, I resolve
it to 1.0 but then it asks me again to resolve the version of
com.mycompany:platform. This clearly is a bug right? I have changed it to
1.0 before so it is no longer a SNAPSHOT???
If you think this is a problem, I will submit it in the JIRA and try to fix
it. I'm just not sure if it's a bug or maybe it's a known issue, or maybe
that's how it is supposed to be.

-- 
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: Archetype Maven On Windows Is Searching for BAT file

[Petar Tahchiev]

Thanks Stuart,

that sounds like it.

2016-04-27 12:32 GMT+02:00 Stuart McCulloch <mccu...@gmail.com>:

> Sounds like https://issues.apache.org/jira/browse/ARCHETYPE-488
>
> On Wednesday, 27 April 2016 at 11:17, Petar Tahchiev wrote:
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-archetype-plugin:2.4:create-from-project
> > (default-cli) on project samplestore: Error configuring command-line.
> > Reason: Maven executable not found at:
> > C:\apache\apache-maven-3.3.9-bin\apache-maven-3.3.9\bin\mvn.bat -> [Help
> 1]
> >
> > It is looking for a bat file, and in my maven 3.3.9 I have mvn.cmd file.
> > When I copy the mvn.cmd and rename it to mvn.bat it works fine.
> >
> > This only happens with maven archetype.
> >
> > Does any one know why is it looking for a bat file?
> >
> > 2016-04-27 12:16 GMT+02:00 Petar Tahchiev <paranoia...@gmail.com
> (mailto:paranoia...@gmail.com)>:
> >
> > > Hi guys,
> > >
> > > I'm on windows 10 now (yeah I know). I have a project and I want to
> > > generate archetype out of it.
> > >
> > > I do the command that works on linux but now it gives this:
> > >
> > >
> > >
> > >
> > > --
> > > 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
> > >
> >
> >
> >
> >
> > --
> > 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
> >
> >
>
>
>


-- 
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: Archetype Maven On Windows Is Searching for BAT file

[Petar Tahchiev]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-archetype-plugin:2.4:create-from-project
(default-cli) on project samplestore: Error configuring command-line.
Reason: Maven executable not found at:
C:\apache\apache-maven-3.3.9-bin\apache-maven-3.3.9\bin\mvn.bat -> [Help 1]

It is looking for a bat file, and in my maven 3.3.9 I have mvn.cmd file.
When I copy the mvn.cmd and rename it to mvn.bat it works fine.

This only happens with maven archetype.

Does any one know why is it looking for a bat file?

2016-04-27 12:16 GMT+02:00 Petar Tahchiev <paranoia...@gmail.com>:

> Hi guys,
>
> I'm on windows 10 now (yeah I know). I have a project and I want to
> generate archetype out of it.
>
> I do the command that works on linux but now it gives this:
>
>
>
>
> --
> 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
>



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

Archetype Maven On Windows Is Searching for BAT file

[Petar Tahchiev]

Hi guys,

I'm on windows 10 now (yeah I know). I have a project and I want to
generate archetype out of it.

I do the command that works on linux but now it gives this:




-- 
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: Re: Re: Does doxia render velocity macros in site

[Petar Tahchiev]

Hi Michael,

I have a custom theme, but what you have written doesn't work. It gives me:

[ERROR] ResourceManager : unable to find resource
'C:\test\src\site\asciidoc/macro.vm' in any resource loader.

Anyways, I think it's a nice feature, but I'll just leave it like this.

Thanks for the reply

2016-04-20 15:04 GMT+02:00 Michael Osipov <1983-01...@gmx.net>:

> If your parse.vm lives next to your template.vm, call #parse('parse.vm')
> and
> your macro should be available to the rest. Though, I have not tried that.
> You will probably have to create a custom skin. You should really create
> complete sample project.
>
> Michael
>
> > Gesendet: Mittwoch, 20. April 2016 um 14:51 Uhr
> > Von: "Petar Tahchiev" <paranoia...@gmail.com>
> > An: "Maven Developers List" <dev@maven.apache.org>
> > Betreff: Re: Re: Does doxia render velocity macros in site
> >
> > Indeed,
> >
> > with MSITE 3.5.1 I can add my macro in a .vm file next to my
> documentation,
> > but since i have 50 modules in my project and they are require this macro
> > it kind of makes it unusable. I was hoping to have it declared in my
> theme
> > just once, and then reference it from every module.
> >
> > 2016-04-20 13:13 GMT+02:00 Michael Osipov <1983-01...@gmx.net>:
> >
> > > > Here's the test repo:
> > > >
> > > > https://github.com/ptahchiev/maven-velocity-macro
> > >
> > > Cloned and tested. Upgrade to MSITE 3.5.1 and your pain will go away.
> > > #parse/#include
> > > has been resolved with DOXIASITETOOLS 1.7.1/MSITE 3.5.1.
> > >
> > > Michael
> > >
> > > > 2016-04-20 8:57 GMT+02:00 Petar Tahchiev <paranoia...@gmail.com>:
> > > >
> > > > > Ok,
> > > > >
> > > > > here's what I've tried:
> > > > >= NOMACRO: I create a file properties.vm, right next to my
> > > > > index.adoc.vm and inside it I put
> > > > >
> > > > >   #set($a = "Petar")
> > > > >   $a
> > > > >
> > > > >   then inside my index.adoc.vm I put
> > > > >   #parse("properties.vm")
> > > > >
> > > > >   [ERROR] Max recursion depth reached (10) File stack: >
> > > > > C:\workspace\test\src\site\asciidoc\index.adoc.vm > properties.vm >
> > > > > properties.vm > properties.vm > properties.vm > properties.vm >
> > > > > properties.vm > properties.vm > properties.vm > properties.vm
> > > > >
> > > > >= MACRO: again I create properties.vm right next to my
> index.adoc.vm
> > > > > and inside it I put
> > > > >
> > > > >   #macro( petar )
> > > > >   Petar
> > > > >   #end
> > > > >
> > > > >then inside the index.adoc.vm I put:
> > > > >
> > > > >  #parse("properties.vm")
> > > > >  #petar()
> > > > >
> > > > > and I get
> > > > >
> > > > > [ERROR] Max recursion depth reached (10) File stack: >
> > > > > C:\workspace\test\src\site\asciidoc\index.adoc.vm > properties.vm >
> > > > > properties.vm > properties.vm > properties.vm > properties.vm >
> > > > > properties.vm > properties.vm > properties.vm > properties.vm
> > > > >
> > > > >  = MACRO IN THEME: I put properties.vm right next to site.vm
> in my
> > > > > theme and I reference it from index.adov.vm with
> > > #parse("properties.vm")
> > > > > and maven does not find the file.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I'll try to make a test project.
> > > > >
> > > > >
> > > > >
> > > > > 2016-04-20 8:42 GMT+02:00 Michael Osipov <micha...@apache.org>:
> > > > >
> > > > >> Am 2016-04-20 um 08:35 schrieb Petar Tahchiev:
> > > > >>
> > > > >>> Hi Michael,
> > > > >>>
> > > > >>> I had a chat with Herve last night, and he mentioned this is
> > > actually not
> > > > >>> possible. If one wants to use velocity macros one must put it in
> the
> > > site
> > > > >>> (if you put the

Re: Re: Does doxia render velocity macros in site

[Petar Tahchiev]

Indeed,

with MSITE 3.5.1 I can add my macro in a .vm file next to my documentation,
but since i have 50 modules in my project and they are require this macro
it kind of makes it unusable. I was hoping to have it declared in my theme
just once, and then reference it from every module.

2016-04-20 13:13 GMT+02:00 Michael Osipov <1983-01...@gmx.net>:

> > Here's the test repo:
> >
> > https://github.com/ptahchiev/maven-velocity-macro
>
> Cloned and tested. Upgrade to MSITE 3.5.1 and your pain will go away.
> #parse/#include
> has been resolved with DOXIASITETOOLS 1.7.1/MSITE 3.5.1.
>
> Michael
>
> > 2016-04-20 8:57 GMT+02:00 Petar Tahchiev <paranoia...@gmail.com>:
> >
> > > Ok,
> > >
> > > here's what I've tried:
> > >= NOMACRO: I create a file properties.vm, right next to my
> > > index.adoc.vm and inside it I put
> > >
> > >   #set($a = "Petar")
> > >   $a
> > >
> > >   then inside my index.adoc.vm I put
> > >   #parse("properties.vm")
> > >
> > >   [ERROR] Max recursion depth reached (10) File stack: >
> > > C:\workspace\test\src\site\asciidoc\index.adoc.vm > properties.vm >
> > > properties.vm > properties.vm > properties.vm > properties.vm >
> > > properties.vm > properties.vm > properties.vm > properties.vm
> > >
> > >= MACRO: again I create properties.vm right next to my index.adoc.vm
> > > and inside it I put
> > >
> > >   #macro( petar )
> > >   Petar
> > >   #end
> > >
> > >then inside the index.adoc.vm I put:
> > >
> > >  #parse("properties.vm")
> > >  #petar()
> > >
> > > and I get
> > >
> > > [ERROR] Max recursion depth reached (10) File stack: >
> > > C:\workspace\test\src\site\asciidoc\index.adoc.vm > properties.vm >
> > > properties.vm > properties.vm > properties.vm > properties.vm >
> > > properties.vm > properties.vm > properties.vm > properties.vm
> > >
> > >  = MACRO IN THEME: I put properties.vm right next to site.vm in my
> > > theme and I reference it from index.adov.vm with
> #parse("properties.vm")
> > > and maven does not find the file.
> > >
> > >
> > >
> > >
> > > I'll try to make a test project.
> > >
> > >
> > >
> > > 2016-04-20 8:42 GMT+02:00 Michael Osipov <micha...@apache.org>:
> > >
> > >> Am 2016-04-20 um 08:35 schrieb Petar Tahchiev:
> > >>
> > >>> Hi Michael,
> > >>>
> > >>> I had a chat with Herve last night, and he mentioned this is
> actually not
> > >>> possible. If one wants to use velocity macros one must put it in the
> site
> > >>> (if you put them in your theme it will not work). Which is a shame,
> as I
> > >>> have a project with 50 submodules and each module requires #myMacro()
> > >>> just
> > >>> once, so I was hoping to have it declared once in the site.vm in the
> > >>> theme,
> > >>> and then use it in each of those modules.
> > >>>
> > >>
> > >> Seriously? We now have #parse() support. That should actually parse
> your
> > >> subtemplate and make the macro available. Have you tried that?
> Templates
> > >> which are not skins are deprecated though and have limited support.
> They
> > >> will be removed in 2.0.
> > >>
> > >> Michael
> > >>
> > >>
> > >> 2016-04-20 8:31 GMT+02:00 Michael Osipov <micha...@apache.org>:
> > >>>
> > >>> Am 2016-04-19 um 20:26 schrieb Petar Tahchiev:
> > >>>>
> > >>>> Hello,
> > >>>>>
> > >>>>> I'm asking this question here, as I don't really see the answer in
> the
> > >>>>> documentation or anywhere else on the internet. If you have a
> website
> > >>>>> document: src/site/asciidoc/index.adoc.vm and you use a velocity
> macro
> > >>>>> in
> > >>>>> it:
> > >>>>>
> > >>>>> # myMacro()
> > >>>>>
> > >>>>>
> > >>>>> I know doxia will process the velocity and it works fine, but will
> it
> > >>>>> also
&

Re: Does doxia render velocity macros in site

[Petar Tahchiev]

Here's the test repo:

https://github.com/ptahchiev/maven-velocity-macro

2016-04-20 8:57 GMT+02:00 Petar Tahchiev <paranoia...@gmail.com>:

> Ok,
>
> here's what I've tried:
>= NOMACRO: I create a file properties.vm, right next to my
> index.adoc.vm and inside it I put
>
>   #set($a = "Petar")
>   $a
>
>   then inside my index.adoc.vm I put
>   #parse("properties.vm")
>
>   [ERROR] Max recursion depth reached (10) File stack: >
> C:\workspace\test\src\site\asciidoc\index.adoc.vm > properties.vm >
> properties.vm > properties.vm > properties.vm > properties.vm >
> properties.vm > properties.vm > properties.vm > properties.vm
>
>= MACRO: again I create properties.vm right next to my index.adoc.vm
> and inside it I put
>
>   #macro( petar )
>   Petar
>   #end
>
>then inside the index.adoc.vm I put:
>
>  #parse("properties.vm")
>  #petar()
>
> and I get
>
> [ERROR] Max recursion depth reached (10) File stack: >
> C:\workspace\test\src\site\asciidoc\index.adoc.vm > properties.vm >
> properties.vm > properties.vm > properties.vm > properties.vm >
> properties.vm > properties.vm > properties.vm > properties.vm
>
>  = MACRO IN THEME: I put properties.vm right next to site.vm in my
> theme and I reference it from index.adov.vm with #parse("properties.vm")
> and maven does not find the file.
>
>
>
>
> I'll try to make a test project.
>
>
>
> 2016-04-20 8:42 GMT+02:00 Michael Osipov <micha...@apache.org>:
>
>> Am 2016-04-20 um 08:35 schrieb Petar Tahchiev:
>>
>>> Hi Michael,
>>>
>>> I had a chat with Herve last night, and he mentioned this is actually not
>>> possible. If one wants to use velocity macros one must put it in the site
>>> (if you put them in your theme it will not work). Which is a shame, as I
>>> have a project with 50 submodules and each module requires #myMacro()
>>> just
>>> once, so I was hoping to have it declared once in the site.vm in the
>>> theme,
>>> and then use it in each of those modules.
>>>
>>
>> Seriously? We now have #parse() support. That should actually parse your
>> subtemplate and make the macro available. Have you tried that? Templates
>> which are not skins are deprecated though and have limited support. They
>> will be removed in 2.0.
>>
>> Michael
>>
>>
>> 2016-04-20 8:31 GMT+02:00 Michael Osipov <micha...@apache.org>:
>>>
>>> Am 2016-04-19 um 20:26 schrieb Petar Tahchiev:
>>>>
>>>> Hello,
>>>>>
>>>>> I'm asking this question here, as I don't really see the answer in the
>>>>> documentation or anywhere else on the internet. If you have a website
>>>>> document: src/site/asciidoc/index.adoc.vm and you use a velocity macro
>>>>> in
>>>>> it:
>>>>>
>>>>> # myMacro()
>>>>>
>>>>>
>>>>> I know doxia will process the velocity and it works fine, but will it
>>>>> also
>>>>> process the macro? I doesn't work for me, and I'm not sure if it is
>>>>> implemented at all. I'm trying to debug it now, but I can't seem to
>>>>> find
>>>>> any setting regarding this.
>>>>>
>>>>>
>>>> Hervé and me have been working at Doxia and the rest lately a lot. Do
>>>> you
>>>> think you could create a sample project for that? I would take a look
>>>> at it.
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>> -
>>>> 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
>>
>>
>
>
> --
> 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
>



-- 
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: Does doxia render velocity macros in site

[Petar Tahchiev]

Ok,

here's what I've tried:
   = NOMACRO: I create a file properties.vm, right next to my index.adoc.vm
and inside it I put

  #set($a = "Petar")
  $a

  then inside my index.adoc.vm I put
  #parse("properties.vm")

  [ERROR] Max recursion depth reached (10) File stack: >
C:\workspace\test\src\site\asciidoc\index.adoc.vm > properties.vm >
properties.vm > properties.vm > properties.vm > properties.vm >
properties.vm > properties.vm > properties.vm > properties.vm

   = MACRO: again I create properties.vm right next to my index.adoc.vm and
inside it I put

  #macro( petar )
  Petar
  #end

   then inside the index.adoc.vm I put:

 #parse("properties.vm")
 #petar()

and I get

[ERROR] Max recursion depth reached (10) File stack: >
C:\workspace\test\src\site\asciidoc\index.adoc.vm > properties.vm >
properties.vm > properties.vm > properties.vm > properties.vm >
properties.vm > properties.vm > properties.vm > properties.vm

 = MACRO IN THEME: I put properties.vm right next to site.vm in my
theme and I reference it from index.adov.vm with #parse("properties.vm")
and maven does not find the file.




I'll try to make a test project.



2016-04-20 8:42 GMT+02:00 Michael Osipov <micha...@apache.org>:

> Am 2016-04-20 um 08:35 schrieb Petar Tahchiev:
>
>> Hi Michael,
>>
>> I had a chat with Herve last night, and he mentioned this is actually not
>> possible. If one wants to use velocity macros one must put it in the site
>> (if you put them in your theme it will not work). Which is a shame, as I
>> have a project with 50 submodules and each module requires #myMacro() just
>> once, so I was hoping to have it declared once in the site.vm in the
>> theme,
>> and then use it in each of those modules.
>>
>
> Seriously? We now have #parse() support. That should actually parse your
> subtemplate and make the macro available. Have you tried that? Templates
> which are not skins are deprecated though and have limited support. They
> will be removed in 2.0.
>
> Michael
>
>
> 2016-04-20 8:31 GMT+02:00 Michael Osipov <micha...@apache.org>:
>>
>> Am 2016-04-19 um 20:26 schrieb Petar Tahchiev:
>>>
>>> Hello,
>>>>
>>>> I'm asking this question here, as I don't really see the answer in the
>>>> documentation or anywhere else on the internet. If you have a website
>>>> document: src/site/asciidoc/index.adoc.vm and you use a velocity macro
>>>> in
>>>> it:
>>>>
>>>> # myMacro()
>>>>
>>>>
>>>> I know doxia will process the velocity and it works fine, but will it
>>>> also
>>>> process the macro? I doesn't work for me, and I'm not sure if it is
>>>> implemented at all. I'm trying to debug it now, but I can't seem to find
>>>> any setting regarding this.
>>>>
>>>>
>>> Hervé and me have been working at Doxia and the rest lately a lot. Do you
>>> think you could create a sample project for that? I would take a look at
>>> it.
>>>
>>> Michael
>>>
>>>
>>>
>>> -
>>> 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
>
>


-- 
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: Does doxia render velocity macros in site

[Petar Tahchiev]

Hi Michael,

I had a chat with Herve last night, and he mentioned this is actually not
possible. If one wants to use velocity macros one must put it in the site
(if you put them in your theme it will not work). Which is a shame, as I
have a project with 50 submodules and each module requires #myMacro() just
once, so I was hoping to have it declared once in the site.vm in the theme,
and then use it in each of those modules.

2016-04-20 8:31 GMT+02:00 Michael Osipov <micha...@apache.org>:

> Am 2016-04-19 um 20:26 schrieb Petar Tahchiev:
>
>> Hello,
>>
>> I'm asking this question here, as I don't really see the answer in the
>> documentation or anywhere else on the internet. If you have a website
>> document: src/site/asciidoc/index.adoc.vm and you use a velocity macro in
>> it:
>>
>> # myMacro()
>>
>>
>> I know doxia will process the velocity and it works fine, but will it also
>> process the macro? I doesn't work for me, and I'm not sure if it is
>> implemented at all. I'm trying to debug it now, but I can't seem to find
>> any setting regarding this.
>>
>
> Hervé and me have been working at Doxia and the rest lately a lot. Do you
> think you could create a sample project for that? I would take a look at it.
>
> Michael
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


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

Does doxia render velocity macros in site

[Petar Tahchiev]

Hello,

I'm asking this question here, as I don't really see the answer in the
documentation or anywhere else on the internet. If you have a website
document: src/site/asciidoc/index.adoc.vm and you use a velocity macro in
it:

# myMacro()


I know doxia will process the velocity and it works fine, but will it also
process the macro? I doesn't work for me, and I'm not sure if it is
implemented at all. I'm trying to debug it now, but I can't seem to find
any setting regarding this.

P.S. myMacro is defined in my own custom theme and I can see in the -X log
that it is being picked up:

[INFO] Rendering 1 Doxia document: 1 asciidoc
[DEBUG] Generating /home/petar/workspace/test/target/site/index.html
[DEBUG] Processing Velocity for index.adoc.vm
[DEBUG] Processing Velocity for template META-INF/maven/site.vm on
index.adoc.vm
[DEBUG] Velocimacro : added VM link: source=META-INF/maven/site.vm
[DEBUG] Velocimacro : added VM image: source=META-INF/maven/site.vm
[DEBUG] Velocimacro : added VM banner: source=META-INF/maven/site.vm
[DEBUG] Velocimacro : added VM links: source=META-INF/maven/site.vm
[DEBUG] Velocimacro : added VM breadcrumbs: source=META-INF/maven/site.vm
[DEBUG] Velocimacro : added VM displayTree: source=META-INF/maven/site.vm
[DEBUG] Velocimacro : added VM menuItem: source=META-INF/maven/site.vm
[DEBUG] Velocimacro : added VM mainMenu: source=META-INF/maven/site.vm
[DEBUG] Velocimacro : added VM copyright: source=META-INF/maven/site.vm
[DEBUG] Velocimacro : added VM publishDate: source=META-INF/maven/site.vm
[DEBUG] Velocimacro : added VM poweredByLogo: source=META-INF/maven/site.vm
[DEBUG] Velocimacro : added VM googleAnalytics:
source=META-INF/maven/site.vm
[DEBUG] Velocimacro : added VM myMacro: source=META-INF/maven/site.vm


-- 
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: [VOTE] Release Apache Maven Doxia Sitetools version 1.7.1

[Petar Tahchiev]

+1 from me

2016-04-02 23:16 GMT+03:00 Hervé BOUTEMY :

> Le samedi 2 avril 2016 21:47:17 Michael Osipov a écrit :
> > Am 2016-04-02 um 21:40 schrieb Hervé BOUTEMY:
> > > Hi,
> > >
> > > On the road to maven-site-plugin 3.5.1, we solved 10 issues:
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320;
> > > version=12334868=Text
> > >
> > > There are still a couple of issues left in JIRA:
> > >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20DOXIASITETOOLS%
> > >
> 20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1256/
> > >
> https://repository.apache.org/content/repositories/maven-1256/org/apache/m
> > >
> aven/doxia/doxia-sitetools/1.7.1/doxia-sitetools-1.7.1-source-release.zip
> > >
> > > Source release checksum(s):
> > > doxia-sitetools-1.7.1-source-release.zip sha1:
> > > a6f704fa7aa3c16e8a73dfdc1542804986ca0662
> > >
> > > Staging site:
> > >
> http://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-LAT
> > > EST/
> > >
> > > Guide to testing staged releases:
> > > http://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for 72 hours.
> >
> > +1
> >
> > Thank you for the great collaboration!
> Thank you, it's great to read that: our discussions to find the right
> solutions regarding initial different approaches were not so easy, but it's
> better to have such negociations than working completely alone
>
> Regards,
>
> Hervé
>
> >
> >
> >
> > -
> > 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
>
>


-- 
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: [VOTE] Release Apache Maven Doxia Sitetools version 1.7

[Petar Tahchiev]

Hello,

+1 from me. Looks good :)

2016-02-13 12:26 GMT+02:00 Karl Heinz Marbaise :

> Hi,
>
> checked SHA1 Ok.
>
> Tested to build with Maven 3.0.5, 3.1.1, 3.2.5, 3.3.9 without any issue
>
> so +1 from me...
>
> Kind regards
> Karl Heinz Marbaise
>
>
> On 2/11/16 11:35 PM, Hervé BOUTEMY wrote:
>
>> Hi,
>>
>> We solved 38 issues:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12330653=Text=12317320
>> (thanks to everybody who contributed)
>>
>> There are still a couple of issues left in JIRA:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20DOXIASITETOOLS%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1249/
>>
>> https://repository.apache.org/content/repositories/maven-1249/org/apache/maven/doxia/doxia-sitetools/1.7/doxia-sitetools-1.7-source-release.zip
>>
>> Source release checksum(s):
>> doxia-sitetools-1.7-source-release.zip sha1:
>> 3068a6e0eebf8dc0c50c6231dbcff4f1d3f2e3e9
>>
>> Staging site:
>>
>> http://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-LATEST/
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
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: [VOTE] Release Apache Maven Doxia version 1.7

[Petar Tahchiev]

+1 from me too.

Great work Herve.

2016-02-06 22:42 GMT+02:00 Karl Heinz Marbaise :

> Hi,
>
> On 2/6/16 8:51 PM, Andreas Gudian wrote:
>
>> +1 from me, although I had to remove the DEPENDENCIES file form the
>> source-zip in order to build it (the rat-config doesn't have an exclusion
>> for the file).
>>
>
> Simply you can run with -Drat.ignoreErrors=true will help...and of course
> the exclusion must be added...
>
>
>
>
>> 2016-02-06 0:10 GMT+01:00 Hervé BOUTEMY :
>>
>> Hi,
>>>
>>> We solved 17 issues:
>>>
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317230=12330561=Text
>>>
>>> There are still a couple of issues left in JIRA:
>>>
>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20DOXIA%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>>>
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-1246/
>>>
>>>
>>> https://repository.apache.org/content/repositories/maven-1246/org/apache/maven/doxia/doxia/1.7/doxia-1.7-source-release.zip
>>>
>>> Source release checksum(s):
>>> doxia-1.7-source-release.zip sha1:
>>> 1971646a8a4b22cce7973889765fb69349c61cbe
>>>
>>> Staging site:
>>> http://maven.apache.org/doxia/doxia-archives/doxia-LATEST/
>>>
>>> Guide to testing staged releases:
>>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>>
>>> Vote open for 72 hours.
>>>
>>> [ ] +1
>>> [ ] +0
>>> [ ] -1
>>>
>>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
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: meeting at FOSDEM

[Petar Tahchiev]

Hello,

I'll try to make it too. Not sure when I will arrive.

2016-01-18 11:43 GMT+02:00 Karl Heinz Marbaise :

> Hi,
>
>
> i will arrive on Friday evening...
>
> Kind regards
> Karl Heinz
>
> On 1/18/16 7:07 AM, Karl Heinz Marbaise wrote:
>
>> Hi Hervé,
>>
>> I'm there on Saturday and Sunday...
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> On 1/18/16 12:52 AM, Hervé BOUTEMY wrote:
>>
>>> Hi,
>>>
>>> Last year, a few Maven devs met at FOSDEM, and this was great.
>>>
>>> This year, who will be there?
>>>
>>> I will be there on sunday.
>>>
>>> Regards,
>>>
>>> Hervé
>>>
>>> https://cwiki.apache.org/confluence/display/COMDEV/FOSDEM+2016
>>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
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: ARCHETYPE-494

[Petar Tahchiev]

Hi Herve,

I pushed the changes in the branch. It should be fine now.

Thanks again for the feedback.

2015-12-18 23:59 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>:

> yes, this sounds reasonable :)
>
> Regards,
>
> Hervé
>
> Le vendredi 18 décembre 2015 21:27:48 Petar Tahchiev a écrit :
> > Hello Herve,
> >
> > thanks for the feedback. Indeed, looking at your email I realize the file
> > naming is not the best. To answer your question - it is both post-create
> > and post-generate. I'm developing a project which later on I make into an
> > archetype using mvn archetype:create-from-project. This script lies in
> the
> > src/main/resources/META-INF/post_create.groovy and after archetype
> creation
> > it ends up in the jar's META-INF/post_create.groovy.
> >
> > I guess the best would be to rename the file to
> > archetype-post-generate.groovy and not use any properties - just detect
> if
> > a file is present
> > then put it in the META-INF during archetype:create-from-project and
> > respectfully if a file called archetype-post-generate.groovy is in the
> > META-INF
> > folder then try to execute it. How does this sound?
> >
> > 2015-12-18 13:48 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>:
> > > Hi Petar,
> > >
> > > Nice work!
> > >
> > > I had a look, and I am a bit confused: is it about post-*generate*, ie
> > > after a
> > > project is generated from an archetype, or about post-*create*, ie
> after
> > > an
> > > archetype project is built from a sample project? See the workflow
> drawing
> > > I
> > > did to try to make that clear [1]
> > >
> > > Because the Jira issue tells that it's about post-generate, but the
> script
> > > constant is ARCHETYPE_POST_GENERATION_SCRIPT =
> > > "META-INF/post_create.groovy"
> > > and a lot of generated classes are about create
> (ArchetypeCreationRequest,
> > > CreateArchetypeFromProjectMojo, FilesetArchetypeCreator).
> > >
> > > I see that Groovy script execution is in
> DefaultFilesetArchetypeGenerator,
> > > then it's really in archetype:generate, but then I don't understand
> what's
> > > the
> > > purpose of the code in archetype:create-from-project. And the
> > > "archetype.postScript" property name doesn't seem a good choice, since
> > > IMHO
> > > causes confusion with "archetype.postPhase":
> > > "archetype.postGenerateScript"
> > > would be better. But even the existence of this property seems
> > > questionable:
> > > can't it just be in a particular location in sample project, so it gets
> > > copied
> > > into META-INF/archetype-post-generate.groovy (whatever the
> > > ARCHETYPE_POST_GENERATION_SCRIPT constant will point to)?
> > >
> > >
> > > I suppose some additional example in plugin's documentation, would make
> > > the
> > > feature easier to understand from an end-user point of view.
> > >
> > >
> > > It's a good idea: let's continue!
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > >
> > > [1] http://maven.apache.org/archetype/maven-archetype-plugin/
> > >
> > > Le jeudi 17 décembre 2015 23:40:28 Petar Tahchiev a écrit :
> > > > Hello all,
> > > >
> > > > I've been having this idea to modify the resulting project after
> > >
> > > generating
> > >
> > > > from a given archetype. In my particular case I'd like to be able to
> > >
> > > delete
> > >
> > > > certain files, modify the pom.xml to add/remove dependencies, etc.
> After
> > > > speaking with Herve Boutemy he suggested it would be a nice addition
> to
> > >
> > > the
> > >
> > > > maven archetype plugin to be able to run a script after the project
> is
> > > > generated from an archetype. I filed the enhancement here:
> > > >
> > > > https://issues.apache.org/jira/browse/ARCHETYPE-494
> > >
> > > > I've also implemented it in a separate branch here:
> > >
> https://git1-us-west.apache.org/repos/asf?p=maven-archetype.git;a=commit;h
> > > =d>
> > > > 60b876506e9b60ffa115c63425f837793fcaacf
> > > >
> > > > The idea is very basic - if the archetype plugin finds a file called
> > > > "post_create.groovy" in META-INF folder it will try to execute it,
> > >
> > > passing
> > >
> > > > all the environment variables to it. I've also added a sample
> test-case.
> > > >
> > > > I'd really like if someone takes a look on it before I merge it.
> Please
> > > > share your comments here.
> > > >
> > > > Thanks.
> > >
> > > -
> > > 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
>
>


-- 
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: ARCHETYPE-494

[Petar Tahchiev]

Hello Herve,

thanks for the feedback. Indeed, looking at your email I realize the file
naming is not the best. To answer your question - it is both post-create
and post-generate. I'm developing a project which later on I make into an
archetype using mvn archetype:create-from-project. This script lies in the
src/main/resources/META-INF/post_create.groovy and after archetype creation
it ends up in the jar's META-INF/post_create.groovy.

I guess the best would be to rename the file to
archetype-post-generate.groovy and not use any properties - just detect if
a file is present
then put it in the META-INF during archetype:create-from-project and
respectfully if a file called archetype-post-generate.groovy is in the
META-INF
folder then try to execute it. How does this sound?

2015-12-18 13:48 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>:

> Hi Petar,
>
> Nice work!
>
> I had a look, and I am a bit confused: is it about post-*generate*, ie
> after a
> project is generated from an archetype, or about post-*create*, ie after an
> archetype project is built from a sample project? See the workflow drawing
> I
> did to try to make that clear [1]
>
> Because the Jira issue tells that it's about post-generate, but the script
> constant is ARCHETYPE_POST_GENERATION_SCRIPT =
> "META-INF/post_create.groovy"
> and a lot of generated classes are about create (ArchetypeCreationRequest,
> CreateArchetypeFromProjectMojo, FilesetArchetypeCreator).
>
> I see that Groovy script execution is in DefaultFilesetArchetypeGenerator,
> then it's really in archetype:generate, but then I don't understand what's
> the
> purpose of the code in archetype:create-from-project. And the
> "archetype.postScript" property name doesn't seem a good choice, since IMHO
> causes confusion with "archetype.postPhase": "archetype.postGenerateScript"
> would be better. But even the existence of this property seems
> questionable:
> can't it just be in a particular location in sample project, so it gets
> copied
> into META-INF/archetype-post-generate.groovy (whatever the
> ARCHETYPE_POST_GENERATION_SCRIPT constant will point to)?
>
>
> I suppose some additional example in plugin's documentation, would make the
> feature easier to understand from an end-user point of view.
>
>
> It's a good idea: let's continue!
>
> Regards,
>
> Hervé
>
>
> [1] http://maven.apache.org/archetype/maven-archetype-plugin/
>
> Le jeudi 17 décembre 2015 23:40:28 Petar Tahchiev a écrit :
> > Hello all,
> >
> > I've been having this idea to modify the resulting project after
> generating
> > from a given archetype. In my particular case I'd like to be able to
> delete
> > certain files, modify the pom.xml to add/remove dependencies, etc. After
> > speaking with Herve Boutemy he suggested it would be a nice addition to
> the
> > maven archetype plugin to be able to run a script after the project is
> > generated from an archetype. I filed the enhancement here:
> >
> > https://issues.apache.org/jira/browse/ARCHETYPE-494
> >
> > I've also implemented it in a separate branch here:
> >
> >
> https://git1-us-west.apache.org/repos/asf?p=maven-archetype.git;a=commit;h=d
> > 60b876506e9b60ffa115c63425f837793fcaacf
> >
> > The idea is very basic - if the archetype plugin finds a file called
> > "post_create.groovy" in META-INF folder it will try to execute it,
> passing
> > all the environment variables to it. I've also added a sample test-case.
> >
> > I'd really like if someone takes a look on it before I merge it. Please
> > share your comments here.
> >
> > Thanks.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


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

Modello Pull Request

[Petar Tahchiev]

Hi guys,

I've been playing with the MavenXpp3Reader/MavenXpp3Writer lately. I
managed to generate a pom.xml but my maven-rat-plugin failed because my
generated pom.xml did not have the appropriate license header. Then I
decided to add a new field in the MavenXpp3Writer called "fileComment". I
modified the code so that if this field is not null, we use the string that
is set as a comment on file level. Now I can do this:

org.apache.maven.model.io.xpp3.MavenXpp3Writer writer = new
org.apache.maven.model.io.xpp3.MavenXpp3Writer();
writer.setFileComment("My comment");
writer.write(new FileWriter(file), model);

and the generated pom.xml has a "My comment" on top.

It's all in here:
https://github.com/codehaus-plexus/modello/pull/3

Please someone review and merge.

Thanks.

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

ARCHETYPE-494

[Petar Tahchiev]

Hello all,

I've been having this idea to modify the resulting project after generating
from a given archetype. In my particular case I'd like to be able to delete
certain files, modify the pom.xml to add/remove dependencies, etc. After
speaking with Herve Boutemy he suggested it would be a nice addition to the
maven archetype plugin to be able to run a script after the project is
generated from an archetype. I filed the enhancement here:

https://issues.apache.org/jira/browse/ARCHETYPE-494

I've also implemented it in a separate branch here:

https://git1-us-west.apache.org/repos/asf?p=maven-archetype.git;a=commit;h=d60b876506e9b60ffa115c63425f837793fcaacf

The idea is very basic - if the archetype plugin finds a file called
"post_create.groovy" in META-INF folder it will try to execute it, passing
all the environment variables to it. I've also added a sample test-case.

I'd really like if someone takes a look on it before I merge it. Please
share your comments here.

Thanks.

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

OSGEO sync

[Petar Tahchiev]

Hi guys,

I use some artifacts from OSGEO (http://www.osgeo.org/) in my build, and
they have their own maven repository
http://download.osgeo.org/webdav/geotools/ which is super slow and my build
fails because the connection times out. So I asked them why they don't
publish to the maven central and their main concern is that they release
quite frequently and a lof of artifacts each month. So they ask me if the
maven central repository has some MB threshold per month. Do you know of
such quota? If not what would be the best way to go - via nexus?

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

Re: [RESULT] [VOTE] Release Apache Maven Archetype version 2.4 - TAKE 2

[Petar Tahchiev]

Oh,

i'm sorry - I didn't mean to mess it up. About the promotion to maven
central I checked it is already there, that's why I sent the email:

http://repo1.maven.org/maven2/org/apache/maven/archetype/archetype-catalog/

The announcement template I copied from the previous maven-archetype
announcement email (version 2.3).

http://mail-archives.apache.org/mod_mbox/maven-dev/201503.mbox/%3CCALhtWke9JodkXyMRGij%3DnYhqx0yJWuQd5WVhxBP2f-L3cPcgkA%40mail.gmail.com%3E


2015-08-15 20:50 GMT+03:00 Karl Heinz Marbaise khmarba...@gmx.de:

 Hi Petar,

 On 8/15/15 6:58 PM, Petar Tahchiev wrote:

 One more thing,

 I'm lacking some privileges in the JIRA so I cannot mark 2.4 as released
 and create 2.5 - if someone could do that for me.


 I can do so...

 I'm writing the official announcement now, as I see the 2.4 release is
 already in the central.


 First you don't follow the templates we have for announcement mails...nor
 do you follow the release procedure[1]...

 The release procedure says you have to promote the artifacts for maven
 central and than wait until it's synched to central which takes usually 4-6
 hours..would means you have to wait until tomorrow for sending out the
 announcement mail otherwise it could cause confusion if someone tries to
 use it after the announcement mails has arrived...and it will fail...

 Furthermore the announcement mails has a template which should be used
 for  copypaste

 If you check the one here:

 http://mail-archives.apache.org/mod_mbox/maven-announce/201507.mbox/%3C20150715185154.0533D185C7%40minotaur.apache.org%3E

 In the meantime you should really follow the template cause we encouraged
 to add important informations to the announcement mail[2].


 [1]:
 https://maven.apache.org/developers/release/maven-project-release-procedure.html
 [2]: https://issues.apache.org/jira/browse/MNGSITE-183



 Cheers, Petar.

 2015-08-15 19:57 GMT+03:00 Petar Tahchiev paranoia...@gmail.com:

 Whew,

 thanks Karl, you have no idea how close to a heart-attack I was :

 2015-08-15 19:57 GMT+03:00 Karl Heinz Marbaise khmarba...@gmx.de:

 Hi Petar,

 take a look here[1]...looks the same...
 so no problem..

 [1]: http://maven.apache.org/maven-release/maven-release-plugin/

 On 8/15/15 6:44 PM, Petar Tahchiev wrote:

 Guys,

 I just did the svnpubsub commands for the website and the image now on
 the top looks broken to me.

 https://maven.apache.org/archetype/index.html

 Do you think they look ok - I really hope I didn't screw it :(


 Kind regardsKarl 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




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

[RESULT] [VOTE] Release Apache Maven Archetype version 2.4 - TAKE 2

[Petar Tahchiev]

Hi,

the vote has passed with the following result:

+1 binding Karl Heinz Marbaise, Herve Boutemy, Olivier Lamy
+1 non-binding Petar Tahchiev

I will promote the artifacts to the central repo.

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

Re: [VOTE] Release Apache Maven Archetype version 2.4 - TAKE 2

[Petar Tahchiev]

OK,

I also vote +1 and thus the vote has passed with 3PMC votes from:

Karl Heinz Marbaise
Herve Boutemy
Olivier Lamy

and also my binding vote:
Petar Tahchiev


2015-08-13 2:17 GMT+03:00 Olivier Lamy ol...@apache.org:

 +1

 do not miss to put your key here:
 http://svn.apache.org/repos/asf/maven/project/KEYS



 On 11 August 2015 at 04:06, Petar Tahchiev paranoia...@gmail.com wrote:

  OK,
 
  here's the take two. Please pay extra attention as I haven't made a
 release
  for a long time now.
 
  We solved 10 issues:
 
 
 https://issues.apache.org/jira/browse/ARCHETYPE-483?jql=project%20%3D%20ARCHETYPE%20AND%20fixVersion%20%3D%202.4%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC
 
  There are still a couple of issues left in JIRA:
 
 
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARCHETYPE%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-1204/
 
 
 https://repository.apache.org/content/repositories/maven-1204/org/apache/maven/archetype/maven-archetype/2.4/maven-archetype-2.4-source-release.zip
 
  Source release checksum(s):
  maven-archetype-2.4-source-release.zip sha1:
  e0afe445f1bb7c9c8e557d59d035e5ae3854f7f1
 
 
  Staging site:
  http://maven.apache.org/archetype-archives/archetype-LATEST
 
  Guide to testing staged releases:
  http://maven.apache.org/guides/development/guide-testing-releases.html
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  --
  Regards, Petar!
  Karlovo, Bulgaria.
  ---
  Public PGP Key at:
  http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x19658550C3110611
  Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
 



 --
 Olivier Lamy
 http://twitter.com/olamy | http://linkedin.com/in/olamy




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

[ANN] Apache Maven Archetype 2.4 Released

[Petar Tahchiev]

The Apache Maven team is pleased to announce the release of the Apache
Maven Archetype, version 2.4

Archetype is a tool for setting up new Maven projects.

Release Notes are here:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317122version=12330295

Enjoy,

-The Apache Maven team

Re: [RESULT] [VOTE] Release Apache Maven Archetype version 2.4 - TAKE 2

[Petar Tahchiev]

One more thing,

I'm lacking some privileges in the JIRA so I cannot mark 2.4 as released
and create 2.5 - if someone could do that for me.
I'm writing the official announcement now, as I see the 2.4 release is
already in the central.

Cheers, Petar.

2015-08-15 19:57 GMT+03:00 Petar Tahchiev paranoia...@gmail.com:

 Whew,

 thanks Karl, you have no idea how close to a heart-attack I was :

 2015-08-15 19:57 GMT+03:00 Karl Heinz Marbaise khmarba...@gmx.de:

 Hi Petar,

 take a look here[1]...looks the same...
 so no problem..

 [1]: http://maven.apache.org/maven-release/maven-release-plugin/

 On 8/15/15 6:44 PM, Petar Tahchiev wrote:

 Guys,

 I just did the svnpubsub commands for the website and the image now on
 the top looks broken to me.

 https://maven.apache.org/archetype/index.html

 Do you think they look ok - I really hope I didn't screw it :(


 Kind regardsKarl Heinz Marbaise






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




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




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

Re: [RESULT] [VOTE] Release Apache Maven Archetype version 2.4 - TAKE 2

[Petar Tahchiev]

Whew,

thanks Karl, you have no idea how close to a heart-attack I was :

2015-08-15 19:57 GMT+03:00 Karl Heinz Marbaise khmarba...@gmx.de:

 Hi Petar,

 take a look here[1]...looks the same...
 so no problem..

 [1]: http://maven.apache.org/maven-release/maven-release-plugin/

 On 8/15/15 6:44 PM, Petar Tahchiev wrote:

 Guys,

 I just did the svnpubsub commands for the website and the image now on
 the top looks broken to me.

 https://maven.apache.org/archetype/index.html

 Do you think they look ok - I really hope I didn't screw it :(


 Kind regardsKarl Heinz Marbaise






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




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

Re: [RESULT] [VOTE] Release Apache Maven Archetype version 2.4 - TAKE 2

[Petar Tahchiev]

Actually I will need some help from a PMC member, because according to this
one:

https://issues.apache.org/jira/browse/INFRA-5945

I don't have permissions to copy the zip in the Apache Distribution Area.

2015-08-15 18:00 GMT+03:00 Petar Tahchiev paranoia...@gmail.com:

 Hi,

 the vote has passed with the following result:

 +1 binding Karl Heinz Marbaise, Herve Boutemy, Olivier Lamy
 +1 non-binding Petar Tahchiev

 I will promote the artifacts to the central repo.

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




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

Re: [RESULT] [VOTE] Release Apache Maven Archetype version 2.4 - TAKE 2

[Petar Tahchiev]

Guys,

I just did the svnpubsub commands for the website and the image now on the
top looks broken to me.

https://maven.apache.org/archetype/index.html

Do you think they look ok - I really hope I didn't screw it :(

2015-08-15 18:38 GMT+03:00 Karl Heinz Marbaise khmarba...@gmx.de:

 Hi Petar,

 I have copied the release artifacts to the distribution area.

 furthermore i have updated the board report.


 On 8/15/15 5:14 PM, Petar Tahchiev wrote:

 Actually I will need some help from a PMC member, because according to
 this one:

 https://issues.apache.org/jira/browse/INFRA-5945

 I don't have permissions to copy the zip in the Apache Distribution Area.

 2015-08-15 18:00 GMT+03:00 Petar Tahchiev paranoia...@gmail.com
 mailto:paranoia...@gmail.com:

 Hi,

 the vote has passed with the following result:

 +1 binding Karl Heinz Marbaise, Herve Boutemy, Olivier Lamy
 +1 non-binding Petar Tahchiev

 I will promote the artifacts to the central repo.

 --
 Regards, Petar!
 Karlovo, Bulgaria.
 ---
 Public PGP Key at:
 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=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




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

Re: svn commit: r1695142 - /maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java

[Petar Tahchiev]

OK,

sorry I wasn't aware that user specifying an input encoding for xml file
would be considered as introducing a bug. Great for the test-case - I will
revert my changes and work for a fix in the MarkdownParser. Would
overriding the getType() method of the MarkdownParser be considered as a
valid solution?

2015-08-12 2:42 GMT+03:00 herve.bout...@free.fr:

 IIUC, your concerns are about Mardown: if Markdown parser has a bug, don't
 hesitate to fix it
 but do not break content for normal XML parsers, like fml or xdoc

 since your change did not make unit tests fail, this proves unit tests are
 too weak: I just improved them in r1695408 to fail (and show clearly what
 you are breaking)
 and I reopened DOXIASITETOOLS-104

 You're probably right that making Markdown parser *extend* XhtmlParser is
 probably wrong: it should *use* an XhtmlParser, but not extend it

 Regards,

 Hervé

 - Mail original -
 De: Petar Tahchiev paranoia...@gmail.com
 À: Maven Developers List dev@maven.apache.org
 Envoyé: Mardi 11 Août 2015 11:36:28
 Objet: Re: svn commit: r1695142 -
 /maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java

 Hi Herve,

 I did this because seems like a parser can be of type XML even if it's not
 parsing only XML - for example the MarkdownParser (which is in doxia and
 extends from the XmlParser) getType() returns 2 (XML parser type). I guess
 there are two ways to go here - 1) first would be to allow the user to
 force an encoding. It's his/hers decision and he/she takes the
 responsibility. 2) Would be to override the XmlParser:getType() method in
 MarkdownParser and make it return 0 (UNKNOWN_TYPE). To me this would lead
 to inconsistency, because the MarkdownParser extends from XmlParser, but
 returns another type. Furthermore I don't agree markdown syntax is in fact
 xml syntax.


 2015-08-11 11:04 GMT+03:00 herve.bout...@free.fr:

  wow, I don't like this
  in XML, encoding is self provided
 
  with such feature, an XML-invalid document can be read by Maven (and
 Maven
  only, since it is XML-invalid)
 
  I'm -1 on this: we can't help people make Maven-specific pseudo XML
 
  Regards,
 
  Hervé
 
  - Mail original -
  De: ptahch...@apache.org
  À: comm...@maven.apache.org
  Envoyé: Lundi 10 Août 2015 20:00:00
  Objet: svn commit: r1695142 -
 
 /maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
 
  Author: ptahchiev
  Date: Mon Aug 10 18:00:00 2015
  New Revision: 1695142
 
  URL: http://svn.apache.org/r1695142
  Log:
  Check for user's provided encoding, and only if it's null then use the
  encoding of the xml document. Closes [DOXIASITETOOLS-104]
 
  Modified:
 
 
 maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
 
  Modified:
 
 maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
  URL:
 
 http://svn.apache.org/viewvc/maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java?rev=1695142r1=1695141r2=1695142view=diff
 
 
 ==
  ---
 
 maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
  (original)
  +++
 
 maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
  Mon Aug 10 18:00:00 2015
  @@ -389,7 +389,14 @@ public class DefaultSiteRenderer
   switch ( parser.getType() )
   {
   case Parser.XML_TYPE:
  -reader = ReaderFactory.newXmlReader( doc );
  +if ( siteContext.getInputEncoding() != null )
  +{
  +reader = ReaderFactory.newReader( doc,
  siteContext.getInputEncoding() );
  +}
  +else
  +{
  +reader = ReaderFactory.newXmlReader( doc );
  +}
   if ( siteContext.isValidate() )
   {
   reader = validate( reader, resource );
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 


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

 -
 To unsubscribe, e-mail: dev-unsubscr

Re: svn commit: r1695142 - /maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java

[Petar Tahchiev]

Hi Herve,

I did this because seems like a parser can be of type XML even if it's not
parsing only XML - for example the MarkdownParser (which is in doxia and
extends from the XmlParser) getType() returns 2 (XML parser type). I guess
there are two ways to go here - 1) first would be to allow the user to
force an encoding. It's his/hers decision and he/she takes the
responsibility. 2) Would be to override the XmlParser:getType() method in
MarkdownParser and make it return 0 (UNKNOWN_TYPE). To me this would lead
to inconsistency, because the MarkdownParser extends from XmlParser, but
returns another type. Furthermore I don't agree markdown syntax is in fact
xml syntax.


2015-08-11 11:04 GMT+03:00 herve.bout...@free.fr:

 wow, I don't like this
 in XML, encoding is self provided

 with such feature, an XML-invalid document can be read by Maven (and Maven
 only, since it is XML-invalid)

 I'm -1 on this: we can't help people make Maven-specific pseudo XML

 Regards,

 Hervé

 - Mail original -
 De: ptahch...@apache.org
 À: comm...@maven.apache.org
 Envoyé: Lundi 10 Août 2015 20:00:00
 Objet: svn commit: r1695142 -
 /maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java

 Author: ptahchiev
 Date: Mon Aug 10 18:00:00 2015
 New Revision: 1695142

 URL: http://svn.apache.org/r1695142
 Log:
 Check for user's provided encoding, and only if it's null then use the
 encoding of the xml document. Closes [DOXIASITETOOLS-104]

 Modified:

 maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java

 Modified:
 maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
 URL:
 http://svn.apache.org/viewvc/maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java?rev=1695142r1=1695141r2=1695142view=diff

 ==
 ---
 maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
 (original)
 +++
 maven/doxia/doxia-sitetools/trunk/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java
 Mon Aug 10 18:00:00 2015
 @@ -389,7 +389,14 @@ public class DefaultSiteRenderer
  switch ( parser.getType() )
  {
  case Parser.XML_TYPE:
 -reader = ReaderFactory.newXmlReader( doc );
 +if ( siteContext.getInputEncoding() != null )
 +{
 +reader = ReaderFactory.newReader( doc,
 siteContext.getInputEncoding() );
 +}
 +else
 +{
 +reader = ReaderFactory.newXmlReader( doc );
 +}
  if ( siteContext.isValidate() )
  {
  reader = validate( reader, resource );



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




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

[CANCELLED] [VOTE] Release Apache Maven Archetype version 2.4

[Petar Tahchiev]

Ok,

according to the -1 votes I'm cancelling the first vote. I'll start another
one later on.

-- Forwarded message --
From: Petar Tahchiev paranoia...@gmail.com
Date: 2015-08-09 22:21 GMT+03:00
Subject: Re: [VOTE] Release Apache Maven Archetype version 2.4
To: Maven Developers List dev@maven.apache.org


Ok,

Let's close this vote. I will revert, fix it and perform a new release.

Thank you.

2015-08-09 21:49 GMT+03:00 Karl Heinz Marbaise khmarba...@gmx.de:

 Hi Petar,

 checked SHA1 Ok..

 unfortunately i have found an issue by running IT's etc. from the release
 zip archive...via:

 Maven 3.3.3,

 mvn -Prun-its clean verify


 So i have to give -1 here...


 The IT expected to have an empty folder which i assume should be already
 checked in, but that can't work with Git, cause in Git you can't checkin
 empty folders. You need to make setup.groovy etc. to create that empty
 folder before running the integration test.


 INFO] Post-archetype-generation invoker exit code: 0
 [INFO] run script
 /Users/kama/Downloads/maven-archetype-2.4/maven-archetype-plugin/target/it/build-archetype-ignore-eol-encoding/target/test-classes/projects/basic/verify.groovy
 [DEBUG] Running script with GroovyScriptInterpreter:
 /Users/kama/Downloads/maven-archetype-2.4/maven-archetype-plugin/target/it/build-archetype-ignore-eol-encoding/target/test-classes/projects/basic/verify.groovy
 [INFO] Running post-build script:
 /Users/kama/Downloads/maven-archetype-2.4/maven-archetype-plugin/target/it/build-archetype-ignore-eol-encoding/target/test-classes/projects/basic/verify.groovy
 [DEBUG] Error evaluating post-build script
 /Users/kama/Downloads/maven-archetype-2.4/maven-archetype-plugin/target/it/build-archetype-ignore-eol-encoding/target/test-classes/projects/basic/verify.groovy,
 Assertion failed:

 assert new
 File(basedir,reference/src/main/resources/empty-directory).exists()
||   |
||  false
|
 /Users/kama/Downloads/maven-archetype-2.4/maven-archetype-plugin/target/it/build-archetype-ignore-eol-encoding/target/test-classes/projects/basic


 /Users/kama/Downloads/maven-archetype-2.4/maven-archetype-plugin/target/it/build-archetype-ignore-eol-encoding/target/test-classes/projects/basic/reference/src/main/resources/empty-directory

 Assertion failed:

 assert new
 File(basedir,reference/src/main/resources/empty-directory).exists()
||   |
||  false
|
 /Users/kama/Downloads/maven-archetype-2.4/maven-archetype-plugin/target/it/build-archetype-ignore-eol-encoding/target/test-classes/projects/basic


 /Users/kama/Downloads/maven-archetype-2.4/maven-archetype-plugin/target/it/build-archetype-ignore-eol-encoding/target/test-classes/projects/basic/reference/src/main/resources/empty-directory



 PS.: Can you please follow the full release procedure template which
 contains also the full path to the release.zip file...makes it easier to
 download instead of using the browser to find the zip file location so i
 can use curl instead



 On 8/9/15 8:18 PM, Petar Tahchiev wrote:

 Hi,

 We solved 9 issues:

 https://issues.apache.org/jira/browse/ARCHETYPE-483?jql=project%20%3D%20ARCHETYPE%20AND%20fixVersion%20%3D%202.4%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC

 There are still a couple of issues left in JIRA:

 https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARCHETYPE%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

 Staging repo:
 https://repository.apache.org/content/repositories/maven-1203/


 Staging site:
 http://maven.apache.org/archetype-archives/archetype-LATEST

 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1



 Kind regards
 Karl Heinz Marbaise


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




-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611



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

[VOTE] Release Apache Maven Archetype version 2.4 - TAKE 2

[Petar Tahchiev]

OK,

here's the take two. Please pay extra attention as I haven't made a release
for a long time now.

We solved 10 issues:
https://issues.apache.org/jira/browse/ARCHETYPE-483?jql=project%20%3D%20ARCHETYPE%20AND%20fixVersion%20%3D%202.4%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC

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

Staging repo:
https://repository.apache.org/content/repositories/maven-1204/
https://repository.apache.org/content/repositories/maven-1204/org/apache/maven/archetype/maven-archetype/2.4/maven-archetype-2.4-source-release.zip

Source release checksum(s):
maven-archetype-2.4-source-release.zip sha1:
e0afe445f1bb7c9c8e557d59d035e5ae3854f7f1


Staging site:
http://maven.apache.org/archetype-archives/archetype-LATEST

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

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

Releasing Maven-Archetype 2.4

[Petar Tahchiev]

Hello,

I'm trying to release archetype 2.4 and I have some questions. I'm
following this guide here:

http://www.apache.org/dev/publishing-maven-artifacts.html#prepare-release

and I everything up to step 4 stage the release for a vote. I just checked
the git and I can see 2 commits that bumped up already the version to
2.5-SNAPSHOT:

https://git-wip-us.apache.org/repos/asf?p=maven-archetype.git;a=summary

Is this normal? I mean I haven't done the release yet, shouldn't it stay
2.4-SNAPSHOT until the release is ready? I hope I didn't screw it up.

Should I proceed with step 4 -

mvn release:perform

?
Thank you.
-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Re: maven-archetype git commits not sent to commits@m.a.o?

[Petar Tahchiev]

Hi Herve,

I was preparing a release for maven archetype and was just about to do mvn
release:perform. Do you want me to stop it? Also if you found some issues
should I revert my git changes in the git (the version is now bumped to
2.5-SNAPSHOT)?

2015-08-09 18:41 GMT+03:00 Benson Margulies bimargul...@gmail.com:

 I'd suggest an INFRA ticket.

 On Sun, Aug 9, 2015 at 11:37 AM,  herve.bout...@free.fr wrote:
  Hi,
 
  I just found Petar git commits, but didn't see them in commits@m.a.o
 (then reported little issues somewhat late as I didn't notice them earlier)
 
  Is there some missing configuration on this repo?
  Are there other Maven git repos with such missing configuration?
 
  PLease some git expert at ASF help us...
 
  Regards,
 
  Hervé
 
  -
  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




-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

[VOTE] Release Apache Maven Archetype version 2.4

[Petar Tahchiev]

Hi,

We solved 9 issues:
https://issues.apache.org/jira/browse/ARCHETYPE-483?jql=project%20%3D%20ARCHETYPE%20AND%20fixVersion%20%3D%202.4%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC

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

Staging repo:
https://repository.apache.org/content/repositories/maven-1203/


Staging site:
http://maven.apache.org/archetype-archives/archetype-LATEST

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Re: maven-archetype git commits not sent to commits@m.a.o?

[Petar Tahchiev]

Hello,

I did everything up to the point where I have to close my staging
repository on nexus, but I can't :( It fails to close it with the following
error:

Event: Failed: Signature Validation
Sunday, August 09, 2015 19:52:54 EEST (GMT+0300)
typeIdsignature-stagingfailureMessageNo public key: Key with id:
(6572f9b3f929fa27) was not able to be located on http://gpg-keyserver.de/.
Upload your public key and try the operation again.failureMessageNo public
key: Key with id: (6572f9b3f929fa27) was not able to be located on
http://pool.sks-keyservers.net:11371. Upload your public key and try the
operation again.failureMessageNo public key: Key with id:
(6572f9b3f929fa27) was not able to be located on http://pgp.mit.edu:11371.
Upload your public key and try the operation again.failureMessageNo public
key: Key with id: (6572f9b3f929fa27) was not able to be located on
http://gpg-keyserver.de/. Upload your public key and try the operation
again.failureMessageNo public key: Key with id: (6572f9b3f929fa27) was not
able to be located on http://pool.sks-keyservers.net:11371. Upload your
public key and try the operation again.failureMessageNo public key: Key
with id: (6572f9b3f929fa27) was not able to be located on
http://pgp.mit.edu:11371. Upload your public key and try the operation
again.failureMessageNo public key: Key with id: (6572f9b3f929fa27) was not
able to be located on http://gpg-keyserver.de/. Upload your public key and
try the operation again.failureMessageNo public key: Key with id:
(6572f9b3f929fa27) was not able to be located on
http://pool.sks-keyservers.net:11371. Upload your public key and try the
operation again.failureMessageNo public key: Key with id:
(6572f9b3f929fa27) was not able to be located on http://pgp.mit.edu:11371.
Upload your public key and try the operation again.failureMessageNo public
key: Key with id: (6572f9b3f929fa27) was not able to be located on
http://gpg-keyserver.de/. Upload your public key and try the operation
again.failureMessageNo public key: Key with id: (6572f9b3f929fa27) was not
able to be located on http://pool.sks-keyservers.net:11371. Upload your
public key and try the operation again.failureMessageNo public key: Key
with id: (6572f9b3f929fa27) was not able to be located on
http://pgp.mit.edu:11371. Upload your public key and try the operation
again.failureMessageNo public key: Key with id: (6572f9b3f929fa27) was not
able to be located on http://gpg-keyserver.de/. Upload your public key and
try the operation again.failureMessageNo public key: Key with id:
(6572f9b3f929fa27) was not able to be located on
http://pool.sks-keyservers.net:11371. Upload your public key and try the
operation again.failureMessageNo public key: Key with id:
(6572f9b3f929fa27) was not able to be located on http://pgp.mit.edu:11371.
Upload your public key and try the operation again.failureMessageNo public
key: Key with id: (6572f9b3f929fa27) was not able to be located on
http://gpg-keyserver.de/. Upload your public key and try the operation
again.failureMessageNo public key: Key with id: (6572f9b3f929fa27) was not
able to be located on http://pool.sks-keyservers.net:11371. Upload your
public key and try the operation again.failureMessageNo public key: Key
with id: (6572f9b3f929fa27) was not able to be located on
http://pgp.mit.edu:11371. Upload your public key and try the operation
again.failureMessageNo public key: Key with id: (6572f9b3f929fa27) was not
able to be located on http://gpg-keyserver.de/. Upload your public key and
try the operation again.failureMessageNo public key: Key with id:
(6572f9b3f929fa27) was not able to be located on
http://pool.sks-keyservers.net:11371. Upload your public key and try the
operation again.failureMessageNo public key: Key with id:
(6572f9b3f929fa27) was not able to be located on http://pgp.mit.edu:11371.
Upload your public key and try the operation again.failureMessageNo public
key: Key with id: (6572f9b3f929fa27) was not able to be located on
http://gpg-keyserver.de/. Upload your public key and try the operation
again.failureMessageNo public key: Key with id: (6572f9b3f929fa27) was not
able to be located on http://pool.sks-keyservers.net:11371. Upload your
public key and try the operation again.failureMessageNo public key: Key
with id: (6572f9b3f929fa27) was not able to be located on
http://pgp.mit.edu:11371. Upload your public key and try the operation
again.failureMessageNo public key: Key with id: (6572f9b3f929fa27) was not
able to be located on http://gpg-keyserver.de/. Upload your public key and
try the operation again.failureMessageNo public key: Key with id:
(6572f9b3f929fa27) was not able to be located on
http://pool.sks-keyservers.net:11371. Upload your public key and try the
operation again.failureMessageNo public key: Key with id:
(6572f9b3f929fa27) was not able to be located on http://pgp.mit.edu:11371.
Upload your public key and try the operation again.failureMessageNo public
key: Key with id: (6572f9b3f929fa27) was not able to be located 

Re: [VOTE] Release Apache Maven Archetype version 2.4

[Petar Tahchiev]

Ok,

Let's close this vote. I will revert, fix it and perform a new release.

Thank you.

2015-08-09 21:49 GMT+03:00 Karl Heinz Marbaise khmarba...@gmx.de:

 Hi Petar,

 checked SHA1 Ok..

 unfortunately i have found an issue by running IT's etc. from the release
 zip archive...via:

 Maven 3.3.3,

 mvn -Prun-its clean verify


 So i have to give -1 here...


 The IT expected to have an empty folder which i assume should be already
 checked in, but that can't work with Git, cause in Git you can't checkin
 empty folders. You need to make setup.groovy etc. to create that empty
 folder before running the integration test.


 INFO] Post-archetype-generation invoker exit code: 0
 [INFO] run script
 /Users/kama/Downloads/maven-archetype-2.4/maven-archetype-plugin/target/it/build-archetype-ignore-eol-encoding/target/test-classes/projects/basic/verify.groovy
 [DEBUG] Running script with GroovyScriptInterpreter:
 /Users/kama/Downloads/maven-archetype-2.4/maven-archetype-plugin/target/it/build-archetype-ignore-eol-encoding/target/test-classes/projects/basic/verify.groovy
 [INFO] Running post-build script:
 /Users/kama/Downloads/maven-archetype-2.4/maven-archetype-plugin/target/it/build-archetype-ignore-eol-encoding/target/test-classes/projects/basic/verify.groovy
 [DEBUG] Error evaluating post-build script
 /Users/kama/Downloads/maven-archetype-2.4/maven-archetype-plugin/target/it/build-archetype-ignore-eol-encoding/target/test-classes/projects/basic/verify.groovy,
 Assertion failed:

 assert new
 File(basedir,reference/src/main/resources/empty-directory).exists()
||   |
||  false
|
 /Users/kama/Downloads/maven-archetype-2.4/maven-archetype-plugin/target/it/build-archetype-ignore-eol-encoding/target/test-classes/projects/basic


 /Users/kama/Downloads/maven-archetype-2.4/maven-archetype-plugin/target/it/build-archetype-ignore-eol-encoding/target/test-classes/projects/basic/reference/src/main/resources/empty-directory

 Assertion failed:

 assert new
 File(basedir,reference/src/main/resources/empty-directory).exists()
||   |
||  false
|
 /Users/kama/Downloads/maven-archetype-2.4/maven-archetype-plugin/target/it/build-archetype-ignore-eol-encoding/target/test-classes/projects/basic


 /Users/kama/Downloads/maven-archetype-2.4/maven-archetype-plugin/target/it/build-archetype-ignore-eol-encoding/target/test-classes/projects/basic/reference/src/main/resources/empty-directory



 PS.: Can you please follow the full release procedure template which
 contains also the full path to the release.zip file...makes it easier to
 download instead of using the browser to find the zip file location so i
 can use curl instead



 On 8/9/15 8:18 PM, Petar Tahchiev wrote:

 Hi,

 We solved 9 issues:

 https://issues.apache.org/jira/browse/ARCHETYPE-483?jql=project%20%3D%20ARCHETYPE%20AND%20fixVersion%20%3D%202.4%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC

 There are still a couple of issues left in JIRA:

 https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARCHETYPE%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

 Staging repo:
 https://repository.apache.org/content/repositories/maven-1203/


 Staging site:
 http://maven.apache.org/archetype-archives/archetype-LATEST

 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1



 Kind regards
 Karl Heinz Marbaise


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




-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

[VOTE] Release Apache Maven Archetype version 2.4

[Petar Tahchiev]

Hi,

We solved 9 issues:
https://issues.apache.org/jira/browse/ARCHETYPE-483?jql=project%20%3D%20ARCHETYPE%20AND%20fixVersion%20%3D%202.4%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC

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

Staging repo:
https://repository.apache.org/content/repositories/maven-1204/
https://repository.apache.org/content/repositories/maven-1204/org/apache/maven/archetype/maven-archetype/2.4/maven-archetype-2.4-source-release.zip

Source release checksum(s):
maven-archetype-2.4-source-release.zip sha1:
e0afe445f1bb7c9c8e557d59d035e5ae3854f7f1

Staging site:
http://maven.apache.org/archetype-archives/archetype-LATEST

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

[VOTE] Release Apache Maven Archetype version 2.4

[Petar Tahchiev]

Hi,

it should be fine now :)

We solved 9 issues:
https://issues.apache.org/jira/browse/ARCHETYPE-483?jql=project%20%3D%20ARCHETYPE%20AND%20fixVersion%20%3D%202.4%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC

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

Staging repo:
https://repository.apache.org/content/repositories/maven-1204/
https://repository.apache.org/content/repositories/maven-1204/org/apache/maven/archetype/maven-archetype/2.4/maven-archetype-2.4-source-release.zip

Source release checksum(s):
maven-archetype-2.4-source-release.zip sha1:
e0afe445f1bb7c9c8e557d59d035e5ae3854f7f1


Staging site:
http://maven.apache.org/archetype-archives/archetype-LATEST

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1
-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Re: [VOTE] Release Apache Maven Archetype version 2.4

[Petar Tahchiev]

Sorry guys, gmail is absolutely stupid - I said new email but had this one
opened to copy the url-s, and now it added it as a response :( .. I'll send
one not as a response to this thread.

2015-08-09 23:46 GMT+03:00 Petar Tahchiev paranoia...@gmail.com:

 Hi,

 We solved 9 issues:

 https://issues.apache.org/jira/browse/ARCHETYPE-483?jql=project%20%3D%20ARCHETYPE%20AND%20fixVersion%20%3D%202.4%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC

 There are still a couple of issues left in JIRA:

 https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARCHETYPE%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

 Staging repo:
 https://repository.apache.org/content/repositories/maven-1204/

 https://repository.apache.org/content/repositories/maven-1204/org/apache/maven/archetype/maven-archetype/2.4/maven-archetype-2.4-source-release.zip

 Source release checksum(s):
 maven-archetype-2.4-source-release.zip sha1:
 e0afe445f1bb7c9c8e557d59d035e5ae3854f7f1

 Staging site:
 http://maven.apache.org/archetype-archives/archetype-LATEST

 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 --
 Regards, Petar!
 Karlovo, Bulgaria.
 ---
 Public PGP Key at:
 https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611




-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Jira Permissions

[Petar Tahchiev]

Hello all,

is it just the infrastructure team that can grant JIRA permissions?  I
raised a ticket here 2 days ago

https://issues.apache.org/jira/browse/INFRA-10082

but there doesn't seem to be much activity on it.
If someone else from the team could grant me rights to resolve issues, I'd
much appreciate it.

Thanks.

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Archetype dependencies

[Petar Tahchiev]

Hey guys,

here's what I want to build: I'd like to be able to pass some dependency
information on the command line during creating a concrete project from an
archetype. For example given the following archetype pom.xml:
-
dependencies
dependency
groupIdsomething/groupId
artifactIdsomething/artifactId
version1.2.3/version
/dependency
*${coreDependencies}*
/dependencies
--

and issuing the following command:

--
mvn archetype:generate -DarchetypeGroupId=blah
-DarchetypeArtifactId=my-archetype -DarchetypeVersion=0.6-SNAPSHOT
-DgroupId=foo -DartifactId=bar -Dversion=1.0 -Dpackage=com.foo.bar
-DinteractiveMode=false -D*coreDependencies*
=com.first:myfirstDependency:1.0-SNAPSHOT,com.second:mysecondDependnecy:1.0-SNAPSHOT,com.third:myThirdDepenency:1.0-SNAPSHOT
--

would generate the following pom.xml:

-
dependencies
dependency
groupIdsomething/groupId
artifactIdsomething/artifactId
version1.2.3/version
/dependency
dependency
groupIdcom.first/groupId
artifactIdmyFirstDependency/artifactId
version1.0-SNAPSHOT/version
/dependency
dependency
groupIdcom.second/groupId
artifactIdmySecondDependency/artifactId
version1.0-SNAPSHOT/version
/dependency
dependency
groupIdcom.third/groupId
artifactIdmyThirdDependency/artifactId
version1.0-SNAPSHOT/version
/dependency
/dependencies
-

If you don't have any objections I will probably start working on this over
the weekend. I'd like to know if this would be useful to any of you, so
feedback (positive or negative) is always welcome.

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Re: Maven archetype version

[Petar Tahchiev]

Yep all done now,

https://github.com/apache/maven-archetype/blob/master/pom.xml

shows 2.4-SNAPSHOT.

2015-04-27 16:27 GMT+03:00 Benson Margulies bimargul...@gmail.com:

 I created https://issues.apache.org/jira/browse/INFRA-9529 to poke at
 this.


 On Sun, Apr 26, 2015 at 4:26 PM, Stuart McCulloch mccu...@gmail.com
 wrote:

  So… https://git-wip-us.apache.org/repos/asf/maven-archetype.git
  (read+write) has the post git-svn commits and the 2.3 release tag
 
  While… git://git.apache.org/maven-archetype.git (read-only) only has the
  git-svn commits and is the one mirrored to github
 
  Should git://git.apache.org/maven-archetype.git now be pulling from
  https://git-wip-us.apache.org/repos/asf/maven-archetype.git instead of
  git-svn like other Maven git repos?
 
  On Sunday, 26 April 2015 at 21:01, Stuart McCulloch wrote:
 
   Odd, this view shows several commits in the canonical repository that
  aren’t in github, including the 2.3 release tag:
  
  
 https://git-wip-us.apache.org/repos/asf?p=maven-archetype.git;a=shortlog
  
   but checking out the canonical repository from git://
  git.apache.org/maven-archetype.git (
  http://git.apache.org/maven-archetype.git) doesn’t show these commits
 




-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Maven archetype version

[Petar Tahchiev]

Hi guys,

I can see in central version 2.3 of the maven-archetype plugin is out:

http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/

but at the same time in master pom.xml in github the version is 2.3-SNAPSHOT

https://github.com/apache/maven-archetype/blob/master/maven-archetype-plugin/pom.xml

Is there something I'm missing?

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Re: Maven Web Site

[Petar Tahchiev]

Hmm..

not that my opinion matters, but I'm more inclined towards: -0. Yes that's
right minus zero. And I'll tell you why. It's a good theme, the look is
slightly better than the existing one (hence +1), but I feel that if we go
for it we will never get the time to create a better site-plugin (using
asciidoctor or any other modern, extensible technology) (hence the -1). The
existing website I believe is written in plain markdown (I'm not sure the
site plugin supports even Markdown Extra, or Github Flavored Markdown)
which gives not many options when it comes to formatting.

So in the end I believe my vote would be -0.


2015-04-05 8:37 GMT+03:00 Hervé BOUTEMY herve.bout...@free.fr:

 +1

 the only real problem I see is the left column that is too big: I don't
 know
 if it can be tweaked through CSS
 But even with that, this version is really better

 one minor issue: icon is missing in
 http://khmarbaise.github.io/maven-site/download.html

 really great enhancement!

 Regards,

 Hervé

 Le dimanche 5 avril 2015 01:20:22 Karl Heinz Marbaise a écrit :
  Hi,
 
  what do you think about the following:
 
  http://khmarbaise.github.io/maven-site/
 
  Just did some very simple things...but in my opinion it looks better
  than the current site? WDYT ?
 
  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




-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Re: Jekyll experiment

[Petar Tahchiev]

Hello all,

A few months ago I was inspired by spring framework and Oliver Gierke to
rewrite my whole documentation using Asciidoctor. Turned out the
asciidoctor-maven plugin has some limitations so I spent some time with
Herve Boutemy last weekend to discuss a few pull requests I created for the
maven-asciidoctor-plugin. Basically the bottom of the problem seems to be
the doxia sink API which sanitizes the produced HTML5 result and removes a
lot of the attributes. This is due to the fact that doxia does not provide
html5 parser so the asciidoctor plugin is forced to extend the xhtml
parser. So in terms of html5 some tags have different meaning. For instance
in html5 the i tag is considered an icon and what asciidoctor is
producing:

i class=fa icon-note title=Note/i

doxia sink api treats as italics tags and removes the class and title
attributes to become: i/i

The end result is that the documentation css does not style the output
properly.
The solution for me is to probably create an HTML5 parser in doxia.
Or even better: instead of

Asciidoctor plugin --- creates -- HTML5 -- give it to the HTML5Parser of
doxia -- give it to the sink API -- produce whatever you want (PDF,
docbook, Latex or HTML5)

maybe a better solution is to get rid of the sink API and keep it only for
backward compatibility, but instead allow any new plugins to directly
produce the HTML5 themselves.



2015-03-19 14:02 GMT+02:00 Jeff Jensen jeffjen...@upstairstechnology.com:

 I agree Fred... the reports are very helpful.  I've always thought of it as
 handling two needs: reports and docs; reports basically working OOTB
 and docs as the team decides to hand-create.


 On Wed, Mar 18, 2015 at 10:43 PM, Fred Cooke fred.co...@gmail.com wrote:

  Well, if you created it, then a personal thank you from me for that. I
  would never use it for normal web stuff, but for the autogenerated stuff
  like PMD, checkstyle, findbugs, cross ref code, javadocs, etc etc it's
  GREAT at release time to give you a reference of what was. Or during dev,
  when one feels like it, to create a comprehensive detailed view of the
  state of the code that can be casually navigated through using a browser.
  It has some SVNness in it, which I hate, so I invite you to continue the
  hate for your own reasons :-D
 
  On Thu, Mar 19, 2015 at 4:32 PM, Jason van Zyl ja...@takari.io wrote:
 
   Anyone interested in trying a Jekyll experiment for our website?
 Extract
   the useful documentation we believe there is and try to make working on
  the
   site a pleasurable experience that is easy for users to contribute to?
  
   I'd like to try this because after this last release I'm frankly tired
 of
   looking at our pretty awful website. It's ugly, noisy, unmaintained,
 hard
   to navigate and personally just makes me not want to write anything. I
   would like to like writing documentation again and I think a more
  standard
   tool like Jekyll will help. I honestly dislike doing core releases
  because
   I have to use the site plugin. I created it, I can hate it and I do
 hate
  it.
  
   Even if no one answers I'll try this experiment because I think there's
   only 10-15 useful documents in the whole site so it likely won't take
  long.
  
   Thanks,
  
   Jason
  
   --
   Jason van Zyl
   Founder, Takari and Apache Maven
   http://twitter.com/jvanzyl
   http://twitter.com/takari_io
   -
  
   There's no sense in being precise when you don't even know what you're
   talking about.
  
-- John von Neumann
  
  
  
  
  
  
  
  
  
  
  
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
   For additional commands, e-mail: dev-h...@maven.apache.org
  
  
 




-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Classloader issues

[Petar Tahchiev]

Hi there,

I have the following maven project setup:

master
| module1
| class ClassA (has annotation @Annotation)
| module2
| class ClassB (also has annotation @Annotation)

and I'm building it with maven, and I use an AbstractProcessor during
compilation to find all types annotated with @Annotation. When I build it
from the module1 level it all works fine. The problem appears when I build
it from master level. Then, what happens is I get an exception that class B
cannot be found.

Caused by: org.reflections.ReflectionsException: could not get type
for name ClassB
at org.reflections.ReflectionUtils.forName(ReflectionUtils.java:389)
at org.reflections.ReflectionUtils.forNames(ReflectionUtils.java:398)
at org.reflections.Reflections.getTypesAnnotatedWith(Reflections.java:385)
at org.reflections.Reflections.getTypesAnnotatedWith(Reflections.java:370)

Here's how I find the types annotated with @Annotation:

 final Reflections reflections =
new Reflections(new
ConfigurationBuilder().setUrls(ClasspathHelper.forClassLoader(ClasspathHelper.staticClassLoader())).setScanners(
new TypeAnnotationsScanner(),
new SubTypesScanner()));
return reflections.getTypesAnnotatedWith(Annotation.class);

What happens is that the classloader will find all the jars in my pom.xml
AND also the following url:

/home/petar/workspace/master/./

and then it will be given to Reflections (method scan on line 235 in
Reflections class ) where it will be treated as a SystemDir so reflections
will recursively go thorough all the subfolders and add all the classes it
finds (which also includes module2/target/classes/ClassB.class). Then it
will try to load it and it will produce the error I pasted above. Now i'm
not sure who's passing the master folder to the classpath, but I checked
the maven classpath with -X and I don't see this folder coming from maven.

Any idea who's adding this folder in the classpath, and also how can I
disable adding it?

Thanks a lot.

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Re: [VOTE] Name our mascot: Shotgun vs The Maven Owl

[Petar Tahchiev]

B

2014-12-16 0:26 GMT+02:00 Stephen Connolly stephen.alan.conno...@gmail.com
:

 You raise a fair point, and for that reason I am changing my vote to

 B

 On 15 December 2014 at 13:15, Gary Gregory garydgreg...@gmail.com wrote:
 
  As cute as Shutgun might seem, for some unspecified definition of
  cute, I am sick of hearing about any kind of gun...
 
 
 http://www.chicagotribune.com/news/nationworld/chi-school-shootings-sandy-hook-20141211-story.html
 
  Gary
 
  On Mon, Dec 15, 2014 at 7:30 AM, Jeroen Hoek jer...@lable.org wrote:
  
   B
  
   2014-12-15 12:41 GMT+01:00 Martin Grigorov mgrigo...@apache.org:
B
   
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
   
On Mon, Dec 15, 2014 at 12:39 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:
   
A
   
On 15 December 2014 at 10:39, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 After the run-off round, we are left with two names standing.

 This second vote will be a straight and simple majority wins.

 The vote will be open for at least 72 hours (with the potential of
  an
 extension until I send a message saying that the polls are closed)

 There will be no discussion in this thread, we have talked it all
   enough
 already. If you want to discuss something, please use a different
   thread.

 Vote:

 [A]: Shotgun
 [B]: The Maven Owl

 Thank you very much for your time

 -Stephen

   
  
  
  
   --
   Vriendelijke groeten,
  
   Jeroen Hoek
  
   Lable
   ✉ jer...@lable.org
   ℡ 088 44 20 202
  
   http://lable.org
   KvK № 55984037
   BTW № NL8519.32.411.B.01
  
   -
   To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
   For additional commands, e-mail: users-h...@maven.apache.org
  
  
 
  --
  E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
  Java Persistence with Hibernate, Second Edition
  http://www.manning.com/bauer3/
  JUnit in Action, Second Edition http://www.manning.com/tahchiev/
  Spring Batch in Action http://www.manning.com/templier/
  Blog: http://garygregory.wordpress.com
  Home: http://garygregory.com/
  Tweet! http://twitter.com/GaryGregory
 



-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Re: [VOTE] Run-off for mascot's name

[Petar Tahchiev]

BHK

2014-12-10 10:56 GMT+02:00 Emilio Lopez emiliol...@gmail.com:

 H E K

 Emiliollbb




-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Re: Maven Site Plugin RSS

[Petar Tahchiev]

Hello,

I didn't get any feedback if the RSS/Atom feeds for the site would be of
any benefit for the team, so I decided to implement it. Here's a pull
request

https://github.com/apache/maven-plugins/pull/37

that could be used as a base for this feature. The implementation is far
from perfect, but I believe it can be easily refactored to the desired
quality.

Cheers, Petar.

2014-12-03 18:12 GMT+02:00 Petar Tahchiev paranoia...@gmail.com:

 Hi there,

 I was wondering if it's possible for the maven site plugin to generate RSS
 or Atom feed during site generation. If not do you think it would be
 interesting for the team? It shouldn't be so hard to iterate over the files
 that are in src/site and decorate them with the url from the POM.

 --
 Regards, Petar!
 Karlovo, Bulgaria.
 ---
 Public PGP Key at:
 https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611




-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Maven Site Plugin RSS

[Petar Tahchiev]

Hi there,

I was wondering if it's possible for the maven site plugin to generate RSS
or Atom feed during site generation. If not do you think it would be
interesting for the team? It shouldn't be so hard to iterate over the files
that are in src/site and decorate them with the url from the POM.

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Re: New logo?

[Petar Tahchiev]

Awesome work :) However, I have always pictured Maven as an anteater :))

2014-11-19 19:49 GMT+02:00 Andreas Gudian andreas.gud...@gmail.com:

 I like it. Cute but resolute birdy, and the font looks fresh and modern.

 But wait - did someone shoot a hole right through the owl? You can even see
 the shadow behind it. ;-) Maybe the patch in the middle could be a little
 darker, perhaps with a hint/tint of the surrounding colour?


 2014-11-19 18:19 GMT+01:00 Arnaud Héritier aherit...@gmail.com:

  I love. Thx a lot for this new contribution !
 
  On Wed, Nov 19, 2014 at 6:15 PM, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
 
   I know this kind of fell to the floor...
  
   So here's an attempt at a reboot.
  
   A Maven is an expert or connoisseur
  
   The couché tard is considered to be a wise creature... perhaps it
 sleeps
   in while downloading the interwebs... you should not ignore their cute
   looks either, if crossed they may bite and leave you in pain...
  
   So without further delay I present a suggestion for our mascot and a
   refreshed logo
  
   http://people.apache.org/~stephenc/maven-logo-contest/maven-owl.png
  
   Using the Alte Haas Grotesk Bold font with italic applied from inkscape
   logo. The middle v is changed to the red of the mascot.
  
  
  
   On 16 December 2013 22:35, Stephen Connolly 
   stephen.alan.conno...@gmail.com wrote:
  
   I have been playing with reworking our front page...[image: Inline
   images 1]
  
   I think the fluido skin is a big improvement, I would like to switch
 to
   that...
  
   Only problem I see is that our current logo(s) are very tied to the
 old
   look and feel...
  
   So do we want to see about launching a logo competition. TomEE had
 good
   success with theirs.
  
   Also I'm looking at going with the top-menu version of fluido skin
  rather
   than the left menu... I have a solution to the hidden nature... but
   you'll just have to wait until I sync up with Hervé to find a way to
  get it
   pushed to staging from a branch without blowing up the production site
  to
   see my trickery!
  
   -Stephen
  
  
  
 
 
  --
  -
  Arnaud Héritier
  http://aheritier.net
  Mail/GTalk: aheritier AT gmail DOT com
  Twitter/Skype : aheritier
 




-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Add class folder to maven compiler plugin

[Petar Tahchiev]

Hi guys,

here's an interesting question I can't find the answer to: how do you add a
folder of classes to your classpath of the maven-compiler-plugin? I read on
the internet most people say one should package it and add it in the
repository, but in my case that's a huuge overhead.

Any other suggestions?

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

ParseException when compiling a MOJO

[Petar Tahchiev]

Hi guys,

I'm working on a maven plugin here, and I have a spring configuration that
looks like this:
-
@Configuration
@ComponentScan(basePackages = { com.test})
public class MyMavenPluginConfig extends WebSecurityConfigurerAdapter {
}
-

This all compiles fine. Then what I do is I add a filter type:
-
@Configuration
@ComponentScan(basePackages = { com.test}, includeFilters =
{@ComponentScan.Filter(type = FilterType.REGEX, pattern = *.core.*)})
public class MyMavenPluginConfig extends WebSecurityConfigurerAdapter {
}
-

and I try to compile it, but I get this exception:

[ERROR] Failed to execute goal
org.codehaus.plexus:plexus-maven-plugin:1.3.8:descriptor (default) on
project my-maven-plugin: Failed to extract descriptors: syntax error
@[34,95] in
file:/C:/workspace/test/platform/my-maven-plugin/src/main/java/com/test/maven/plugin/config/MyMavenPluginConfig.java
- [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.codehaus.plexus:plexus-maven-plugin:1.3.8:descriptor (default) on
project my-maven-plug
in: Failed to extract descriptors
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:318)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
extract descriptors
at
org.codehaus.plexus.maven.plugin.AbstractDescriptorMojo.generateDescriptor(AbstractDescriptorMojo.java:137)
at
org.codehaus.plexus.maven.plugin.PlexusDescriptorMojo.execute(PlexusDescriptorMojo.java:60)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: com.thoughtworks.qdox.parser.ParseException: syntax error
@[34,95] in
file:/C:/workspace/test/platform/my-maven-plugin/src/main/java/com/test/maven/plugi
n/config/MyMavenPluginConfig.java
at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:716)
at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:826)
at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:697)
at
com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:300)
at
com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:316)
at
com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:312)
at
com.thoughtworks.qdox.JavaDocBuilder$1.visitFile(JavaDocBuilder.java:369)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:43)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.walk(DirectoryScanner.java:34)
at
com.thoughtworks.qdox.directorywalker.DirectoryScanner.scan(DirectoryScanner.java:52)
 

Re: ParseException when compiling a MOJO

[Petar Tahchiev]

Hi Robert,

thanks - updating to plexus-component-metadata did work.


2014-05-03 20:33 GMT+03:00 Robert Scholte rfscho...@apache.org:

 Hi,

 I'm pretty sure this has already been fixed in the latest version of QDox.

 However, if you go to the site of this plugin[1], you'll see that you
 should use plexus-component-metadata[2].
 If this gives you the same problem, try to upgrade
 org.thoughtworks.qdox:qdox to 1.12.1 by adding this as dependency to the
 plugin.
 If even this doesn't work, I'll have to write a small patch for the
 plugin, so it will be using QDox 2.0-M1

 thanks,
 Robert

 [1] http://plexus.codehaus.org/plexus-maven-plugin/
 [2] http://plexus.codehaus.org/plexus-containers/plexus-
 component-metadata/

 Op Sat, 03 May 2014 18:36:00 +0200 schreef Petar Tahchiev 
 paranoia...@gmail.com:


  Hi guys,

 I'm working on a maven plugin here, and I have a spring configuration that
 looks like this:
 -
 @Configuration
 @ComponentScan(basePackages = { com.test})
 public class MyMavenPluginConfig extends WebSecurityConfigurerAdapter {
 }
 -

 This all compiles fine. Then what I do is I add a filter type:
 -
 @Configuration
 @ComponentScan(basePackages = { com.test}, includeFilters =
 {@ComponentScan.Filter(type = FilterType.REGEX, pattern = *.core.*)})
 public class MyMavenPluginConfig extends WebSecurityConfigurerAdapter {
 }
 -

 and I try to compile it, but I get this exception:

 [ERROR] Failed to execute goal
 org.codehaus.plexus:plexus-maven-plugin:1.3.8:descriptor (default) on
 project my-maven-plugin: Failed to extract descriptors: syntax error
 @[34,95] in
 file:/C:/workspace/test/platform/my-maven-plugin/src/
 main/java/com/test/maven/plugin/config/MyMavenPluginConfig.java
 - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
 goal org.codehaus.plexus:plexus-maven-plugin:1.3.8:descriptor (default)
 on
 project my-maven-plug
 in: Failed to extract descriptors
 at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(
 MojoExecutor.java:216)
 at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(
 MojoExecutor.java:153)
 at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(
 MojoExecutor.java:145)
 at
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
 LifecycleModuleBuilder.java:84)
 at
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
 LifecycleModuleBuilder.java:59)
 at
 org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(
 LifecycleStarter.java:183)
 at
 org.apache.maven.lifecycle.internal.LifecycleStarter.
 execute(LifecycleStarter.java:161)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:318)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
 at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
 at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(
 NativeMethodAccessorImpl.java:57)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(
 DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at
 org.codehaus.plexus.classworlds.launcher.Launcher.
 launchEnhanced(Launcher.java:290)
 at
 org.codehaus.plexus.classworlds.launcher.Launcher.
 launch(Launcher.java:230)
 at
 org.codehaus.plexus.classworlds.launcher.Launcher.
 mainWithExitCode(Launcher.java:414)
 at
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
 Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
 extract descriptors
 at
 org.codehaus.plexus.maven.plugin.AbstractDescriptorMojo.
 generateDescriptor(AbstractDescriptorMojo.java:137)
 at
 org.codehaus.plexus.maven.plugin.PlexusDescriptorMojo.
 execute(PlexusDescriptorMojo.java:60)
 at
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
 DefaultBuildPluginManager.java:106)
 at
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(
 MojoExecutor.java:208)
 ... 19 more
 Caused by: com.thoughtworks.qdox.parser.ParseException: syntax error
 @[34,95] in
 file:/C:/workspace/test/platform/my-maven-plugin/src/
 main/java/com/test/maven/plugi
 n/config/MyMavenPluginConfig.java
 at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.
 java:716)
 at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.
 java:826)
 at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:
 697)
 at
 com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:300)
 at
 com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:316

Re: Developing Maven Archetype

[Petar Tahchiev]

Yeah that was one of the options to generate the archetype from my working
source. However, I release my archetype quite often and is really not
convenient to generate it every time and replace all the package names, and
xmls and class names etc. So I was hoping to get a better solution.


2014-03-09 23:51 GMT+02:00 Chris Graham chrisgw...@gmail.com:

 Generate the archetype from your working source.

 Sent from my iPhone

 On 10/03/2014, at 8:06 AM, Petar Tahchiev paranoia...@gmail.com wrote:

  Hello,
 
  thanks for your responses. Yes, unforutnately, I do need parameterized
 Java
  code (package names, classnames, also xml files, etc..). As I said it's
  pretty complicated project.
  I looked at templating-maven-plugin but it seems that filtering the
  standard src/main/java folder is not supported. Also, I may not
 understand
  the quite your suggestion, but using the templating-maven-plugin will
 also
  break Eclipse as I will be still having ${packageName} in my sources.
 
  I'm kind of surprised that no one else has had this problem before. Does
  this mean that the archetypes are only supposed to work with simple
  projects that are not continuously developed?
 
 
  2014-03-09 22:50 GMT+02:00 Baptiste Mathus bmat...@batmat.net:
 
  Just a quick thought, maybe using some hacky form of a development
 profile
  using the templating-maven-plugin to filter those properties could help?
 
 
  2014-03-09 20:47 GMT+01:00 Benson Margulies bimargul...@gmail.com:
 
  Are you sure that you absolutely need parameterized Java code? There's
  really no good way to work with it. You could instead use the
  maven-shade-plugin to customer-ize your results as part of their
  build.
 
 
  On Sun, Mar 9, 2014 at 3:36 PM, Petar Tahchiev paranoia...@gmail.com
  wrote:
  Hey guys,
 
  here's an interesting question: how do you develop your maven
  archetypes? I
  have a web-project that consists of lots of controllers and jsps, and
 I
  have been developing this for a long time, and I want to keep
  developing
  it. I also want to provide this project to my clients as an archetype
  so
  they can be up-and-running as quickly as possible.
 
  I thought of creating an archetype from my project every time I
 release
  the
  archetype, but that seems really unefficient as I release new versions
  very
  often, and also the archetype is quite complicated.
 
  I also thought to create the archetype once, and keep developing it in
  Eclipse, but that's not possible because for instance the package
 names
  look like this:
 
  package ${packageName};
 
  and of-course Eclipse complains.
 
  So my questions is - if you have a complicated archetype that you keep
  developing over time, how do you develop it? Is there an
  Eclipse/IntelliJ
  plugin for archetype developing?
 
  --
  Regards, Petar!
  Karlovo, Bulgaria.
  ---
  Public PGP Key at:
 
 
 
 https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=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
 
 
 
 
  --
  Baptiste Batmat MATHUS - http://batmat.net
  Sauvez un arbre,
  Mangez un castor !
 
 
 
 
  --
  Regards, Petar!
  Karlovo, Bulgaria.
  ---
  Public PGP Key at:
 
 https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=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




-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Developing Maven Archetype

[Petar Tahchiev]

Hey guys,

here's an interesting question: how do you develop your maven archetypes? I
have a web-project that consists of lots of controllers and jsps, and I
have been developing this for a long time, and I want to keep developing
it. I also want to provide this project to my clients as an archetype so
they can be up-and-running as quickly as possible.

I thought of creating an archetype from my project every time I release the
archetype, but that seems really unefficient as I release new versions very
often, and also the archetype is quite complicated.

I also thought to create the archetype once, and keep developing it in
Eclipse, but that's not possible because for instance the package names
look like this:

package ${packageName};

and of-course Eclipse complains.

So my questions is - if you have a complicated archetype that you keep
developing over time, how do you develop it? Is there an Eclipse/IntelliJ
plugin for archetype developing?

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

Re: Developing Maven Archetype

[Petar Tahchiev]

Hello,

thanks for your responses. Yes, unforutnately, I do need parameterized Java
code (package names, classnames, also xml files, etc..). As I said it's
pretty complicated project.
I looked at templating-maven-plugin but it seems that filtering the
standard src/main/java folder is not supported. Also, I may not understand
the quite your suggestion, but using the templating-maven-plugin will also
break Eclipse as I will be still having ${packageName} in my sources.

I'm kind of surprised that no one else has had this problem before. Does
this mean that the archetypes are only supposed to work with simple
projects that are not continuously developed?


2014-03-09 22:50 GMT+02:00 Baptiste Mathus bmat...@batmat.net:

 Just a quick thought, maybe using some hacky form of a development profile
 using the templating-maven-plugin to filter those properties could help?


 2014-03-09 20:47 GMT+01:00 Benson Margulies bimargul...@gmail.com:

  Are you sure that you absolutely need parameterized Java code? There's
  really no good way to work with it. You could instead use the
  maven-shade-plugin to customer-ize your results as part of their
  build.
 
 
  On Sun, Mar 9, 2014 at 3:36 PM, Petar Tahchiev paranoia...@gmail.com
  wrote:
   Hey guys,
  
   here's an interesting question: how do you develop your maven
  archetypes? I
   have a web-project that consists of lots of controllers and jsps, and I
   have been developing this for a long time, and I want to keep
 developing
   it. I also want to provide this project to my clients as an archetype
 so
   they can be up-and-running as quickly as possible.
  
   I thought of creating an archetype from my project every time I release
  the
   archetype, but that seems really unefficient as I release new versions
  very
   often, and also the archetype is quite complicated.
  
   I also thought to create the archetype once, and keep developing it in
   Eclipse, but that's not possible because for instance the package names
   look like this:
  
   package ${packageName};
  
   and of-course Eclipse complains.
  
   So my questions is - if you have a complicated archetype that you keep
   developing over time, how do you develop it? Is there an
 Eclipse/IntelliJ
   plugin for archetype developing?
  
   --
   Regards, Petar!
   Karlovo, Bulgaria.
   ---
   Public PGP Key at:
  
 
 https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=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
 
 


 --
 Baptiste Batmat MATHUS - http://batmat.net
 Sauvez un arbre,
 Mangez un castor !




-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611