[Patch] (X)HTML5 support for Doxia

[Graham Leggett]

Hi all,

I have submitted the final patch for xhtml5 support for Doxia, as well as 
linked changes to maven-doxia-sitetools and maven-site-plugin to generate html5 
by default.

https://issues.apache.org/jira/browse/DOXIA-575

Regards,
Graham
—


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

Re: [Patch] (X)HTML5 support for Doxia

[Graham Leggett]

On 27 Oct 2018, at 14:22, Graham Leggett  wrote:

> I have submitted the final patch for xhtml5 support for Doxia, as well as 
> linked changes to maven-doxia-sitetools and maven-site-plugin to generate 
> html5 by default.
> 
> https://issues.apache.org/jira/browse/DOXIA-575

Quick bump, anyone had a chance to take a look?

Regards,
Graham
—


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

Re: [VOTE] Release Apache Maven Doxia Sitetools version 1.9

[Graham Leggett]

On 07 Jun 2019, at 14:57, Michael Osipov  wrote:

> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1

+1 (non binding)

Builds and tests run clean in java8 and java10.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Apache Maven Archiver version 3.1.1

[Graham Leggett]

On 13 Jun 2019, at 17:18, Tibor Digana  wrote:

> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1

+1 on java10 and java8.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Apache Maven Doxia Sitetools version 1.9.1

[Graham Leggett]

On 19 Jun 2019, at 23:00, Michael Osipov  wrote:

> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1

+1 on Java8 and Java10.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Maven Site Plugin version 3.8

[Graham Leggett]

On 24 Jun 2019, at 22:45, Michael Osipov  wrote:

> We solved 10 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923&version=12343145
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1518/
> https://repository.apache.org/content/repositories/maven-1518/org/apache/maven/plugins/maven-site-plugin/3.8/maven-site-plugin-3.8-source-release.zip
> 
> Source release checksum(s):
> maven-site-plugin-3.8-source-release
> sha512: 
> 5d2b1bd671052179a27a55ca3bbc5ed82c3a0c3a16f2cfb20b3b06388fc4e4fa71e571d958d93d665df8b4f1add7b47a0480df7e9139ccee77f7ee906485f189
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1

+1 on Java8.

One test failed, however this test also fails in maven-site-plugin v3.7.1, so 
this is not a regression:

[INFO] Building: effective-site/pom.xml
[INFO] run post-build script verify.groovy
[INFO]   effective-site/pom.xml ... FAILED (6.0 
s)
[INFO]   The post-build script did not succeed. assert new File( basedir, 
'effective-site.xml' ).exists()
   | |   |
   | |   false
   | 
/home/gatekeeper/minfrin/src/apache/sandbox/maven/maven-site-plugin-maven-site-plugin-3.7.1/target/it/effective-site
   
/home/gatekeeper/minfrin/src/apache/sandbox/maven/maven-site-plugin-maven-site-plugin-3.7.1/target/it/effective-site/effective-site.xml

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Maven Site Plugin version 3.8.1

[Graham Leggett]

On 01 Jul 2019, at 23:10, Michael Osipov  wrote:

> We solved 11 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923&version=12343145
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1520/
> https://repository.apache.org/content/repositories/maven-1520/org/apache/maven/plugins/maven-site-plugin/3.8.1/maven-site-plugin-3.8.1-source-release.zip
> 
> Source release checksum(s):
> maven-site-plugin-3.8.1-source-release.zip
> sha512: 
> e4e001e848267c50052e2261f98f7b4c0fcc9833d13245c69dc06d26b30f814061048d6bebaef8464120133ffb503c002ddaecdfc9b234801b4ca7729c7a24cd
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1

Like last time, +1 on Java8.

One test failed, however this test also fails in maven-site-plugin v3.7.1, so 
this is not a regression:

[INFO] Building: effective-site/pom.xml
[INFO] run post-build script verify.groovy
[INFO]   effective-site/pom.xml ... FAILED (6.0 
s)
[INFO]   The post-build script did not succeed. assert new File( basedir, 
'effective-site.xml' ).exists()
   | |   |
   | |   false
   | 
/home/gatekeeper/minfrin/src/apache/sandbox/maven/maven-site-plugin-maven-site-plugin-3.7.1/target/it/effective-site
   
/home/gatekeeper/minfrin/src/apache/sandbox/maven/maven-site-plugin-maven-site-plugin-3.7.1/target/it/effective-site/effective-site.xml

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Maven Site Plugin version 3.8.1

[Graham Leggett]

On 04 Jul 2019, at 09:03, Tibor Digana  wrote:

> The build passed successfully after I have used Jetty 9.2.9.v20150224. (no
> need to change our code in the plugin)
> It was the last J7 but v9.x Jetty.

The reasoning in https://github.com/apache/maven-site-plugin/pull/3 
 makes sense to me, 
insecure dependencies need fixing - can you confirm whether Jetty 
9.2.9.v20150224 resolves the insecure dependencies issue fixed by this patch?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Maven Site Plugin version 3.8.1

[Graham Leggett]

On 04 Jul 2019, at 13:12, Tibor Digana  wrote:

> Did you read the Jira and the commit in Git?
> It was written in the way to push Java 8 without any strong reason, sorry
> for that but it's truth.

I’m not following.

Jetty is a compile time dependency of the maven-site-plugin, I believe it’s 
used to make site:run work.

[INFO] +- org.eclipse.jetty:jetty-server:jar:9.4.12.v20180830:compile
[INFO] |  +- javax.servlet:javax.servlet-api:jar:3.1.0:compile
[INFO] |  +- org.eclipse.jetty:jetty-http:jar:9.4.12.v20180830:compile
[INFO] |  \- org.eclipse.jetty:jetty-io:jar:9.4.12.v20180830:compile
[INFO] +- org.eclipse.jetty:jetty-servlet:jar:9.4.12.v20180830:compile
[INFO] |  \- org.eclipse.jetty:jetty-security:jar:9.4.12.v20180830:compile
[INFO] +- org.eclipse.jetty:jetty-webapp:jar:9.4.12.v20180830:compile
[INFO] |  \- org.eclipse.jetty:jetty-xml:jar:9.4.12.v20180830:compile
[INFO] +- org.eclipse.jetty:jetty-util:jar:9.4.12.v20180830:compile

Old versions of jetty pull in insecure dependencies (that’s the point of the 
ticket and patch, as I read it).

The outstanding question is, what is the minimum java version supported by the 
oldest jetty that has fixed secure dependencies? You’ve confirmed Jetty 
9.2.9.v20150224 works with java7 - does that version also have secure 
dependencies?

> I would like to see v9.2 first (after v6) in 3.8.1 and then wait for Maven
> 3.7.0 which will go most probably with J8. We can release Site 3.9.0 and
> use it in bindings in Maven 3.7.0. So we will have strictly segregated
> Maven and plugins before MVN 3.7 and embedded plugins for MVN 3.7+. If we
> move one plugin to J8 then move all but do it for MVN 3.7+.

So would you say you’d prefer to delay fixing 
https://issues.apache.org/jira/browse/MSITE-829 until maven 3.7.0 is a thing?

(I have no opinion at this point, if there are two maven-site-plugin releases, 
one with the fix deferred, and another with the fix, that seems reasonable to 
me).

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Maven Site Plugin version 3.8.1

[Graham Leggett]

On 04 Jul 2019, at 22:04, Michael Osipov  wrote:

>> One test failed, however this test also fails in maven-site-plugin v3.7.1, 
>> so this is not a regression:
>> [INFO] Building: effective-site/pom.xml
>> [INFO] run post-build script verify.groovy
>> [INFO]   effective-site/pom.xml ... FAILED 
>> (6.0 s)
>> [INFO]   The post-build script did not succeed. assert new File( basedir, 
>> 'effective-site.xml' ).exists()
>>| |   |
>>| |   false
>>| 
>> /home/gatekeeper/minfrin/src/apache/sandbox/maven/maven-site-plugin-maven-site-plugin-3.7.1/target/it/effective-site
>>
>> /home/gatekeeper/minfrin/src/apache/sandbox/maven/maven-site-plugin-maven-site-plugin-3.7.1/target/it/effective-site/effective-site.xml
> 
> Can you share why this one fails for you, but not for me on three different 
> operating systems? I'd like to fix this.

This has made my head bleed.

Run the test on its own, and the test passes:

[minfrin@gatekeeper maven-site-plugin-3.8.1]$ mvn invoker:run 
-Dinvoker.test=projects/effective-site*
[INFO] Scanning for projects...
[INFO] 
[INFO] -< org.apache.maven.plugins:maven-site-plugin >-
[INFO] Building Apache Maven Site Plugin 3.8.1
[INFO] [ maven-plugin ]
[INFO] 
[INFO] --- maven-invoker-plugin:3.1.0:run (default-cli) @ maven-site-plugin ---
[INFO] Building: projects/effective-site/pom.xml
[INFO]   projects/effective-site/pom.xml .. SUCCESS 
(5.5 s)
[INFO] -
[INFO] Build Summary:
[INFO]   Passed: 1, Failed: 0, Errors: 0, Skipped: 0
[INFO] -
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  8.349 s
[INFO] Finished at: 2019-07-06T14:37:27+02:00
[INFO] 

Run the whole test suite, and this test fails:

[minfrin@gatekeeper maven-site-plugin-3.8.1]$ mvn install -P run-its
[snip]
[INFO] Building: effective-site/pom.xml
[INFO] run post-build script verify.groovy
[INFO]   effective-site/pom.xml ... FAILED (4.8 
s)
[INFO]   The post-build script did not succeed. assert new File( basedir, 
'effective-site.xml' ).exists()
   | |   |
   | |   false
   | 
/home/gatekeeper/minfrin/src/apache/sandbox/maven/maven-site-plugin-3.8.1/target/it/effective-site
   
/home/gatekeeper/minfrin/src/apache/sandbox/maven/maven-site-plugin-3.8.1/target/it/effective-site/effective-site.xml

I am at a loss as to why - after both tests above, pass and fail, there is no 
file anywhere called target/it/effective-site/effective-site.xml.

The test itself seems straightforward. Create a file called 
effective-site.xml...

[minfrin@gatekeeper maven-site-plugin-3.8.1]$ cat 
src/it/projects/effective-site/invoker.properties
[snip]
invoker.goals = clean site:effective-site
invoker.mavenOpts = -Doutput=effective-site.xml

…and test effective-site.xml exists:

[minfrin@gatekeeper maven-site-plugin-3.8.1]$ cat 
src/it/projects/effective-site/verify.groovy 
[snip]
assert new File( basedir, 'effective-site.xml' ).exists();

Looking at target/it/effective-site/build.log in the failure case, the 
effective site is written to the build.log, and not the -Doutput= like it 
should have been.

Not sure what could cause this, something overriding invoker.mavenOpts?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Maven Site Plugin version 3.8.1

[Graham Leggett]

On 06 Jul 2019, at 15:02, Graham Leggett  wrote:

> I am at a loss as to why - after both tests above, pass and fail, there is no 
> file anywhere called target/it/effective-site/effective-site.xml.
> 
> The test itself seems straightforward. Create a file called 
> effective-site.xml...
> 
> [minfrin@gatekeeper maven-site-plugin-3.8.1]$ cat 
> src/it/projects/effective-site/invoker.properties
> [snip]
> invoker.goals = clean site:effective-site
> invoker.mavenOpts = -Doutput=effective-site.xml
> 
> …and test effective-site.xml exists:
> 
> [minfrin@gatekeeper maven-site-plugin-3.8.1]$ cat 
> src/it/projects/effective-site/verify.groovy 
> [snip]
> assert new File( basedir, 'effective-site.xml' ).exists();
> 
> Looking at target/it/effective-site/build.log in the failure case, the 
> effective site is written to the build.log, and not the -Doutput= like it 
> should have been.
> 
> Not sure what could cause this, something overriding invoker.mavenOpts?

I think this could be caused by different versions of maven plugins being run 
in the two different scenarios. When I ran “invoker:run” directly for the first 
time, a different version of the failsafe plugin was downloaded as opposed to 
when the invoker plugin triggered the tests :

[minfrin@gatekeeper maven-site-plugin-3.8.1]$ mvn invoker:run 
-Dinvoker.test=effective-site
[INFO] Scanning for projects...
Downloading from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-deploy-plugin/2.8.2/maven-deploy-plugin-2.8.2.jar
Downloaded from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-deploy-plugin/2.8.2/maven-deploy-plugin-2.8.2.jar
 (34 kB at 20 kB/s)
Downloading from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-assembly-plugin/3.0.0/maven-assembly-plugin-3.0.0.jar
Downloaded from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-assembly-plugin/3.0.0/maven-assembly-plugin-3.0.0.jar
 (241 kB at 262 kB/s)
Downloading from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-docck-plugin/1.1/maven-docck-plugin-1.1.jar
Downloaded from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-docck-plugin/1.1/maven-docck-plugin-1.1.jar
 (34 kB at 74 kB/s)
Downloading from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-ear-plugin/3.0.1/maven-ear-plugin-3.0.1.pom
Downloaded from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-ear-plugin/3.0.1/maven-ear-plugin-3.0.1.pom
 (11 kB at 30 kB/s)
Downloading from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-ear-plugin/3.0.1/maven-ear-plugin-3.0.1.jar
Downloaded from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-ear-plugin/3.0.1/maven-ear-plugin-3.0.1.jar
 (88 kB at 230 kB/s)
Downloading from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-failsafe-plugin/2.22.0/maven-failsafe-plugin-2.22.0.pom
Downloaded from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-failsafe-plugin/2.22.0/maven-failsafe-plugin-2.22.0.pom
 (12 kB at 32 kB/s)
Downloading from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-failsafe-plugin/2.22.0/maven-failsafe-plugin-2.22.0.jar
Downloaded from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-failsafe-plugin/2.22.0/maven-failsafe-plugin-2.22.0.jar
 (294 kB at 370 kB/s)
Downloading from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-gpg-plugin/1.6/maven-gpg-plugin-1.6.jar
Downloaded from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-gpg-plugin/1.6/maven-gpg-plugin-1.6.jar
 (47 kB at 127 kB/s)
Downloading from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-help-plugin/3.1.0/maven-help-plugin-3.1.0.pom
Downloaded from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-help-plugin/3.1.0/maven-help-plugin-3.1.0.pom
 (9.5 kB at 26 kB/s)
Downloading from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-help-plugin/3.1.0/maven-help-plugin-3.1.0.jar
Downloaded from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-help-plugin/3.1.0/maven-help-plugin-3.1.0.jar
 (64 kB at 164 kB/s)
[INFO] 
[INFO] -< org.apache.maven.plugins:maven-site-plugin >-
[INFO] Building Apache Maven Site Plugin 3.8.1

I think the maven-site-plugin should probably decide what versions of failsafe 
and surefire that it wants to run. The invoker plugin instantiates a whole new 
maven, so I suspect each test needs to decide that versions of failsafe to run 
too.

Regards,
Graham
—




smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Maven Site Plugin version 3.8.1

[Graham Leggett]

On 07 Jul 2019, at 20:51, Michael Osipov  wrote:

> I, too, now see this on the ASF Jenkins instance.
> 
> Can you file an issue and add your finding please? I don't want your effort 
> to be lost in the archives. Someone needs to start digging to find the 
> mismatch. So the IT itself is fine, but the environment is unreliable.

I’ve added the issue here, with a patch:

https://issues.apache.org/jira/browse/MSITE-846

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Maven Site Plugin version 3.8.2

[Graham Leggett]

On 24 Jul 2019, at 21:59, Michael Osipov  wrote:

> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1

+1

:)

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Maven Default Skin version 1.3

[Graham Leggett]

On 28 Jul 2019, at 13:53, Michael Osipov  wrote:

> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1

+1.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Maven Fluido Skin version 1.8

[Graham Leggett]

On 28 Jul 2019, at 22:16, Michael Osipov  wrote:

> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1

+1.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Maven Filtering Plugin should avoid overwriting even when filtering

[Graham Leggett]

On 25 Apr 2020, at 17:12, Robert Oxspring  wrote:

>> I tend to think it does not need any hash but just a lastUpdated
>> track (the most recent file invalidating previous cache, it is enough and
>> faster than any hash computation)
> 
> I’m not totally sure of this. Filtering, for example, is particularly 
> dependant on properties and configuration which aren’t directly linked with a 
> source file change.

Exactly - this is the key limitation.

I think we’re doomed to having to recreate the file each time, because we have 
no way of knowing whether the file has changed until you generate it.

But - there is nothing stopping us, when we detect the file is the same, from 
not updating the original file. This will have the effect of not triggering 
unnecessary downstream changes.

Concrete example: A filter generates a file that is input to a code generator. 
Because the file changes every time, the code generator runs every time, not 
good. But if we detected the file as the same, and didn’t write the filtered 
file, the code generator wouldn’t run, and we would safely avoid an unnecessary 
rebuild.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Maven issue with JDK16 - javac and javadoc

[Graham Leggett]

On 12 Nov 2020, at 14:03, Enrico Olivelli  wrote:

> I have fallen into this issue about Maven + Maven Compiler Plugin + JDK16
> 
> This is the issue on JDK issue tracking
> https://bugs.openjdk.java.net/browse/JDK-8253996
> 
> Basically -Xdoclint:missing does not work anymore when you run javac inside
> the same JVM as Maven core, because the JVM lacks the jdk.javadoc module.
> If you run javac in "fork" mode the problem is not present because the
> external "javac" program loads correctly jdk.javadoc module and is able to
> execute "-Xdoclint"
> 
> it looks like we have to fix it on Maven, I am not sure the problem is
> about maven-compiler-plugin or plexus compiler, as it is because the JVM
> that executes Maven core lacks the jdk.javadoc module.
> 
> On the JDK side it looks like the issue is to be closed as "works for me"
> 
> 
> Thoughts?

I have been smashing my head against the javadoc plugin and 
maven-release-plugin, which keeps failing releases over and over again on the 
basis that the docs can’t be built.

In the absence of a way to fix this, if there is a way to switch this off it 
would help a huge amount.

Regards,
Graham
—


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

Re: Maven issue with JDK16 - javac and javadoc

[Graham Leggett]

On 12 Nov 2020, at 14:50, Graham Leggett  wrote:

> I have been smashing my head against the javadoc plugin and 
> maven-release-plugin, which keeps failing releases over and over again on the 
> basis that the docs can’t be built.
> 
> In the absence of a way to fix this, if there is a way to switch this off it 
> would help a huge amount.

What I eventually discovered was that when building the site, and when building 
the site as part of the release plugin release process, different versions of 
plugins were being selected, despite the versions of the plugins being pinned 
properly in the build section of the pom.

What worked around the problem was pinning the javadoc plugin version in the 
reporting part of the pom.
  

  
maven-javadoc-plugin
3.2.0

  false

  
  
org.apache.maven.plugins
maven-project-info-reports-plugin
3.1.1
  

  
Ideally if the errors that complain about versions not being pinned can also 
tell us specifically _where_ these unpinned versions are declared, this will 
help enormously to take the randomness out of maven released.

Regards,
Graham
—



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

Maven plugin to generate key material for SSL unit tests

[Graham Leggett]

Hi all,

I find myself yet again fixing a bug in an application where client 
certificates don’t work, as the constructors for the code work for the trivial 
case only. The bug is fixed, now I’m looking at how you would unit/integration 
test this. The existing unit test has a checked in self signed cert for testing.

Does there exist a maven plugin that will generate certs and keys for the 
benefit of an integration test?

Regards,
Graham
—


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

Re: Maven plugin to generate key material for SSL unit tests

[Graham Leggett]

On 13 Jun 2022, at 14:18, Delany  wrote:

> https://www.mojohaus.org/keytool/keytool-maven-plugin/plugin-info.html

Thanks for this.

It seems to come close, but the missing piece seems to be the step where the 
CSR is turned into a signed certificate to produce a working trust chain.

I wonder if it's time for a maven-pki-plugin to generate key and cert material 
for unit tests.

Regards,
Graham
—


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

Override the scm details in the maven-project-info-reports-plugin

[Graham Leggett]

Hi all,

The website https://hc.apache.org has no SCM report, primarily because the 
website is in one project, while the actual components are in other projects.

In theory you can override the SCM details in the 
maven-project-info-reports-plugin by following 
https://maven.apache.org/plugins/maven-project-info-reports-plugin/scm-mojo.html,
 but this doesn’t work here - hc.apache.org has many components rather than 
one, and there is no way to suppress the default values to make them vanish.

Does it make sense to add the capability to this report to create a set of 
links to the SCM sections of sub-projects, replacing the website’s scm if 
present?

Regards,
Graham
—


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

Maven search for a class or method on classpath - how?

[Graham Leggett]

Hi all,

I find myself with a large project, not knowing which dependency(ies) is 
transitively providing a given class.

Is there a plugin that will allow a search within a project like this?

I can sort of do something with dependency:list-classes, but this is limited in 
that it will only list classes in one artefact at a time. I want to find a 
class in all artefacts in a project.

Regards,
Graham
—


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

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

[Graham Leggett]

Hi all,

K.

Regards,
Graham
--


> On 9 Dec 2014, at 10:52, Stephen Connolly  
> wrote:
> 
> This is a run-off vote to select the top two options for our new mascot's
> name.
> 
> The entries with the highest number of votes will be selected for the final
> round. If there is only one entry with the highest number of votes then the
> entries with the second highest number of votes will also be included in
> the final round.
> 
> The vote will be open for 72 hours.
> 
> The entries are as follows:
> 
> A. Abraham
> B. Boo
> C. Darth Mowl
> D. Jacob
> E. Kaboom
> F. Moses
> G. Rap
> H. Shotgun
> K. The Maven Owl
> L. Ty
> 
> It is not clear whether all of the above suggestions were completely
> serious, but I have included them anyway for this first round.
> 
> Please respond with at most your top three in order of preference. I may
> not use second or third preferences if we get a sufficient number of votes,
> but in the case of a small poll the additional preferences will help.
> 
> In the event of repeated votes from an individual, only the last cast vote
> as determined by me will count.
> 
> Any other discussion should happen in a separate thread.
> 
> Thanks
> 
> -Stephen

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

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

[Graham Leggett]

On 15 Dec 2014, at 12:39 PM, Stephen Connolly  
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

B.

Regards,
Graham
—


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

maven-site-plugin: Generating (X)HTML5 instead of XHTML - how?

[Graham Leggett]

Hi all,

According to the docs at 
https://maven.apache.org/plugins/maven-site-plugin/examples/creating-content.html
 "Note that Doxia also supports several output formats, the site plugin only 
creates XHTML”.

I would like the maven-site-plugin to have the option to output HTML5 (or 
XHTML5 to be more specific), and from what I can see, maven-site-plugin cannot 
do this today. (correct?)

To support this, I am understanding that the following needs to get done:

- Create an XHTML5 sink for Doxia.
- Teach the maven-site-plugin to optionally use the XHTML5 sink if specified in 
the skin. (or make in mandatory for maven-site-plugin v4.x?)
- (Possibly?) Extend Doxia to support new (X)HTML5 tags.

My question is - am I on the right track? Is there some other work to support 
HTML5 that I may have missed?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: maven-site-plugin: Generating (X)HTML5 instead of XHTML - how?

[Graham Leggett]

On 15 Apr 2018, at 1:29 AM, Hervé BOUTEMY  wrote:

> yes, this will require a xhtml5 Doxia sink
> 
> since each skin defines a site template as direct html source (without Doxia 
> interaction), the maven-site-plugin switch from xhtml to xhtml5 would have to 
> be done on configuration from the skin: looks like a good addition to skin 
> model [1]
> 
> finally, adding tags seems mode complex: Doxia is about having a common API 
> for 
> every format. Perhaps propose an example and we'll see

Thank you for confirming I’m on the right track.

I got here as I was trying to develop a maven skin based on an HTML5 template, 
and I couldn’t find a clean way of getting HTML5 tags through the site plugin.

Let me see what I can come up with.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: maven-site-plugin: Generating (X)HTML5 instead of XHTML - how?

[Graham Leggett]

On 15 Apr 2018, at 1:29 AM, Hervé BOUTEMY  wrote:

> yes, this will require a xhtml5 Doxia sink
> 
> since each skin defines a site template as direct html source (without Doxia 
> interaction), the maven-site-plugin switch from xhtml to xhtml5 would have to 
> be done on configuration from the skin: looks like a good addition to skin 
> model [1]

> [1] https://maven.apache.org/doxia/doxia-sitetools/doxia-skin-model/

Having looked at this in some detail, this is what I've found.

maven-doxia is reasonably straightforward. I’ve added an xhtml5 module, and so 
far this seems to work alongside the other modules.

The maven-site-plugin uses maven-doxia-sitetools to render output. Makes sense.

maven-doxia-sitetools is welded firmly to the xhtml module from maven-doxia - 
most specifically, org.apache.maven.doxia.siterenderer.sink.SiteRendererSink 
extends org.apache.maven.doxia.module.xhtml.XhtmlSink.

The approach I am looking at for this is as follows:

- Add an xhtml5 module to maven-doxia, implementing the stricter XML version of 
HTML5.

- Branch v2.0.x of maven-doxia-sitetools, and in this new branch, shift all 
code that extends org.apache.maven.doxia.module.xhtml.XhtmlSink to extend 
org.apache.maven.doxia.module.xhtml5.Xhtml5Sink instead.

- By default, v2.0.x of maven-doxia-sitetools will produce (X)HTML5.

- Branch v4.0 of maven-site-plugin. This new branch will depend on 
maven-doxia-sitetools v2.0 by default, and will generate HTML5 by default, and 
skins will need to be tweaked accordingly.

- To upgrade from XHTML to (X)HTML5, upgrade your maven-site-plugin in your 
project.

I am in the process of patching the above to make all of this so, but I’d 
appreciate it if I could get confirmation that this approach is sane before I 
get too far into this. Can someone confirm?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [GitHub] minfrin opened a new pull request #10: XHTML5 support for maven-doxia

[Graham Leggett]

On 13 May 2018, at 5:27 PM, GitBox  wrote:

> minfrin opened a new pull request #10: XHTML5 support for maven-doxia
> URL: https://github.com/apache/maven-doxia/pull/10

This was premature - sorry for the noise.

By way of explanation, this is a work-in-progress for XHTML5 support for 
maven-doxia.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Maven Doxia and minimum Java versions

[Graham Leggett]

Hi all,

I would like to clarify what the policy is on maven-doxia and the maven project 
in general, and minimum java versions.

With the XHTML5 work on Doxia, I have managed to keep all changes without a 
requirement to upgrade any dependencies, until I got to maven-doxia-sitetools 
and httpunit, which doesn’t understand any HTML5 tags. My current workaround is 
to simply test that HTML5 tags are present, but ignore their type, and this 
seems good enough for now - no httpunit upgrade needed.

Upgrading httpunit to a version that supports HTML5 and doesn’t suffer from bug 
https://sourceforge.net/p/htmlunit/bugs/1961/ means a minimum java version of 
v1.8.

What is the policy on java versions in maven-doxia? Is it intentionally kept 
behind the curve so old code can be built, or is it acceptable to make java 1.8 
a minimum version?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Maven Doxia and minimum Java versions

[Graham Leggett]

On 15 May 2018, at 11:08 PM, Hervé BOUTEMY  wrote:

> I'm maintaining Doxia and maven-site-plugin for a long time, trying to keep 
> the prerequisites (for end users particularly) as low as possible when I 
> don't 
> have a strong win on upgrading.

+1 - my feeling too.

> Currently, maven-site-plugin (which is what users see, without knowing much 
> about Doxia) requires Java 6 only.
> With Doxia 1.8 / maven-site-plugin 3.7, in fact, there is a little trick: one 
> Doxia module (Markdown) requires Java 7, because of the library used, and I 
> documented how one can downgrade this module if he strictly require to use 
> maven-site-plugin 3.7 with Java 6.
> But for sure, when building maven-site-plugin, I didn't try to add a profile 
> to be able to build with Java 6: Java 7 is required to build maven-site-
> plugin.
> 
> Honestly, for Java 6, maven-site-plugin 3.7 is the last version: now it's 
> time 
> to drop it and require Java 7 if you want newer version of the plugin.
> 
> Then I'm full ok to upgrade Doxia requirement for Doxia 1.9 and maven-site-
> plugin 3.8 to Java 7.
> 
> 
> On httpunit, AFAIK it's only for Doxia tests during its build: I don't have 
> any issue with building Doxia with Java 8 to produce jar that require Java 7 
> only.

How I tripped over this was the enforcer plugin - enforcer found Java 8 code 
being brought in by httpunit and said “no”.

Not knowing a lot about the enforcer plugin, is there a way to build the 
primary artifacts at compliance level v1.6, but build and run the tests at v1.8?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

RE: [VOTE] maven-eclipse-plugin 2.4

[Graham Leggett]

On Thu, July 5, 2007 3:23 pm, Brian E. Fox wrote:

> It's a recurring cycle where we wait and wait and before you know
> it, it's 5 months like it is now with good functionality already sitting
> there.

+1.

Release early, release often.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Allowing Envars

[Graham Leggett]

On Fri, August 31, 2007 12:10 pm, Jason van Zyl wrote:

> As much I don't particularly like them, I've seen so many builds of
> late using envars that I don't think we can turn them off in 2.1.x
> after people have invested in builds that use them. Tonight Vlad and
> I were working on the IDEA integration and there are a few issues
> logged that fail because envars are not currently processed in trunk.
>
> I think we have to live with them now.
>
> If no one objects I will plan to turn them back on.

For the history of what happened when Sun tried to remove support for
environment variables see this:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4199068

Due to overwhelming protest Sun eventually reversed their decision and put
environment variables back in.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: How are the multiproject artifacts resolved in release:prepare?

[Graham Leggett]

On Fri, November 23, 2007 3:35 pm, Jörg Schaible wrote:

> I know why my plugin fails, but I don't know why other maven plugins can
> handle the situation. I did now a bad hack and will look for the attached
> artifact at the same location as the main artifact is located and only if
> I cannot find it locally I will use the ArtifactResolver. Nevertheless I
> am interested in the "proper" solution.

Artificts should only ever be found in one of two locations: the current
project, or the local repository (after possibly downloading it fronm a
central repository, if appropriate).

> This is dangerous and highly discouraged. We have quite a lot of artifacts
> and if the release manager simply performs "release:prepare", but fails to
> perform the release itself, the build will at least fail for the next
> artifact that is dependend on the new release.

This makes no sense - why would the build fail because an artifact is
present? The build should only fail if the artifact is absent, which it
will be if default release:prepare behaviour is followed.

If the concern is that possible unreleased jars end up in the local
repository, then the real problem is that release:prepare is trying to run
a build *after* the change of version number from SNAPSHOT to released,
instead of before.

> With your variant the
> prepared, but not yet released artifact is found in the release manager's
> local repository and he will never recognize that the final artifact has
> neither been build nor deployed.

In our case the person performing a release is responsible for running
both release:prepare and release:perform, making this largely a non issue.

The underlying problem is that maven supports a single common local repo
to look for all artifacts, and I personally believe that it should work
this way. The release:prepare tests should be ideally be done using
SNAPSHOT version numbers, and this problem can be worked around.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How are the multiproject artifacts resolved in release:prepare?

[Graham Leggett]

On Fri, November 23, 2007 10:30 am, Jörg Schaible wrote:

> We use since long ago an own plugin, that accesses a secondary artifact of
> a dependency. This worked like charm ... until now. We have now the new
> situation, that the secondary artifact is build in the same multi project
> build by one subproject and it is used in another one. However,
> release:prepare fails now, since the subproject that makes usage of the
> secondary artifact always tries to access the final-but-not-yet-release
> version.

This looks suspiciously like a problem we encountered, caused by the
assumption of the release plugin that elements within a multi-module
project won't depend on other elements in the same multi-module project,
and where the entire multi-module project has a common version number.

The cause is because the goal that is used to test the build of the code,
doesn't go as far as deploying the artifacts under test into the local
repository, and so module+1 doesn't see the artifacts just generated by
module or module-1.

The workaround is to override this goal to be "clean install", which does
deploy the artifacts into the repo, like this in your root pom:

  
org.apache.maven.plugins
maven-release-plugin
2.0-beta-6

  clean install

  

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

maven-ear-plugin: is har supported or not?

[Graham Leggett]

Hi all,

According to the docs at 
http://maven.apache.org/plugins/maven-ear-plugin/modules.html#harModule, 
it is now at long last possible to build ear files containing har files 
with maven.


Unfortunately, any attempt at adding the config in the docs results in 
this exception:


org.apache.maven.lifecycle.LifecycleExecutionException: Error 
configuring: org.apache.maven.plugins:maven-ear-plugin. Reason: Unable 
to parse the created DOM for plugin configuration


The modules are defined like this:

  

  alchemy
  alchemy-trader


  alchemy
  alchemy-trader

  


Is there something I need to do to my maven v2.0.4 install before it 
will automatically upgrade to the new maven-ear-plugin, assuming I am 
running an older one?


Has the version of the maven-ear-plugin described by the docs been 
released yet?


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: maven-ear-plugin: is har supported or not?

[Graham Leggett]

Stephane Nicoll wrote:


No, it's implemented as from 2.3 which is not yet released. You can
retrieve it on the snapshot repository [1] or you can build the plugin
from source yourself.


Are there any showstoppers preventing its release?

I was very confusing to see the docs for the new plugin released and 
live before the plugin itself.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: maven-ear-plugin: is har supported or not?

[Graham Leggett]

Stephane Nicoll wrote:


Are there any showstoppers preventing its release?


No. I just need to cast a vote and we'll release it.


Here is a non binding +1 for release: +1 :)


I was very confusing to see the docs for the new plugin released and
live before the plugin itself.


Yes, the sites have been deployed recently and we're discussing about
this kind of issues. I think that adding a note somewhere saying that
it's about a X.Y-SNAPSHOT version is a start.


The existence of the snapshot stuff is useful, but there needs to be a 
clear set of docs for the snapshots, and a clear set for the latest 
releases, and it needs to be clear which one you are looking at.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

maven-eclipse-plugin and eclipse:make-artifacts

[Graham Leggett]

Hi all,

According to the docs at 
http://maven.apache.org/plugins/maven-eclipse-plugin/make-artifacts-mojo.html, 
the eclipse plugin can import artifacts from an eclipse installation.


The most recent released plugin disagrees:

[INFO] 


[ERROR] BUILD FAILURE
[INFO] 


[INFO] Required goal not found: eclipse:make-artifacts

Is this another case of snapshot documentation being included in the 
main site?


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

[vote] release maven-ear-plugin

[Graham Leggett]

Hi all,

I would like to propose a release of the maven-ear-plugin.

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

[vote] release maven-eclipse-plugin

[Graham Leggett]

Hi all,

I would like to propose the release of the maven-eclipse-plugin. This 
will bring the eclipse:make-artifacts goal into a non snapshot release.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

NullPointerException in maven-eclipse-plugin

[Graham Leggett]

Hi all,

While trying to run the eclipse:make-artifacts goals against an up to date
eclipse v3.2.1 installation, it bombs out with a NullPointerException like
so:

java.lang.NullPointerException
at
org.apache.maven.plugin.eclipse.MakeArtifactsMojo.processSingleFile(MakeArtifactsMojo.java:288)

The full trace of what it is doing is like so:

[INFO] [eclipse:make-artifacts]
[INFO] Eclipse directory?
/Applications/Eclipse/Eclipse-3.2/
[INFO] Processing file
/Applications/Eclipse/Eclipse-3.2/plugins/com.eviware.soapui.core_0.4.1
[INFO] Building jar: /tmp/mvn-eclipse64714.tmp
[INFO] Missing version for artifact com.eviware.soapui.libs, assuming any
version > 0
[INFO] Installing /tmp/pom-64715.xml to
/Users/minfrin/.m2/repository/com/eviware/soapui/com.eviware.soapui.core/0.4.1/com.eviware.soapui.core-0.4.1.pom
[INFO] Installing /tmp/mvn-eclipse64714.tmp to
/Users/minfrin/.m2/repository/com/eviware/soapui/com.eviware.soapui.core/0.4.1/com.eviware.soapui.core-0.4.1.jar
[INFO] Processing file
/Applications/Eclipse/Eclipse-3.2/plugins/com.eviware.soapui.eclipse.core_0.4.1
[INFO] Building jar: /tmp/mvn-eclipse64716.tmp
[INFO] Missing version for artifact com.eviware.soapui.core, assuming any
version > 0
[INFO] Missing version for artifact org.eclipse.core.runtime, assuming any
version > 0
[INFO] Missing version for artifact org.eclipse.ui, assuming any version > 0
[INFO] Missing version for artifact org.eclipse.ui.console, assuming any
version > 0
[INFO] Missing version for artifact org.eclipse.ui.editors, assuming any
version > 0
[INFO] Missing version for artifact org.eclipse.ui.workbench.texteditor,
assuming any version > 0
[INFO] Missing version for artifact org.eclipse.ui.ide, assuming any
version > 0
[INFO] Missing version for artifact org.eclipse.jdt.core, assuming any
version > 0
[INFO] Missing version for artifact org.eclipse.ant.core, assuming any
version > 0
[INFO] Missing version for artifact org.eclipse.jdt.launching, assuming
any version > 0
[INFO] Missing version for artifact org.eclipse.core.resources, assuming
any version > 0
[INFO] Missing version for artifact org.eclipse.jface.text, assuming any
version > 0
[INFO] Installing /tmp/pom-64717.xml to
/Users/minfrin/.m2/repository/com/eviware/soapui/com.eviware.soapui.eclipse.core/0.4.1/com.eviware.soapui.eclipse.core-0.4.1.pom
[INFO] Installing /tmp/mvn-eclipse64716.tmp to
/Users/minfrin/.m2/repository/com/eviware/soapui/com.eviware.soapui.eclipse.core/0.4.1/com.eviware.soapui.eclipse.core-0.4.1.jar
[INFO] Processing file
/Applications/Eclipse/Eclipse-3.2/plugins/com.eviware.soapui.jbosside.wstools_0.4.1
[INFO] Building jar: /tmp/mvn-eclipse64718.tmp
[INFO] Missing version for artifact com.eviware.soapui.core, assuming any
version > 0
[INFO] Missing version for artifact com.eviware.soapui.eclipse.core,
assuming any version > 0
[INFO] Missing version for artifact org.eclipse.ui, assuming any version > 0
[INFO] Missing version for artifact org.eclipse.core.runtime, assuming any
version > 0
[INFO] Missing version for artifact org.eclipse.ui.editors, assuming any
version > 0
[INFO] Missing version for artifact org.eclipse.jface.text, assuming any
version > 0
[INFO] Missing version for artifact org.eclipse.ui.workbench.texteditor,
assuming any version > 0
[INFO] Missing version for artifact org.eclipse.ui.ide, assuming any
version > 0
[INFO] Missing version for artifact org.eclipse.core.resources, assuming
any version > 0
[INFO] Missing version for artifact org.eclipse.ant.core, assuming any
version > 0
[INFO] Missing version for artifact org.eclipse.jdt.launching, assuming
any version > 0
[INFO] Missing version for artifact org.eclipse.jdt.core, assuming any
version > 0
[INFO] Missing version for artifact org.eclipse.ui.console, assuming any
version > 0
[INFO] Missing version for artifact org.eclipse.ui.navigator, assuming any
version > 0
[INFO] Installing /tmp/pom-64719.xml to
/Users/minfrin/.m2/repository/com/eviware/soapui/com.eviware.soapui.jbosside.wstools/0.4.1/com.eviware.soapui.jbosside.wstools-0.4.1.pom
[INFO] Installing /tmp/mvn-eclipse64718.tmp to
/Users/minfrin/.m2/repository/com/eviware/soapui/com.eviware.soapui.jbosside.wstools/0.4.1/com.eviware.soapui.jbosside.wstools-0.4.1.jar
[INFO] Processing file
/Applications/Eclipse/Eclipse-3.2/plugins/com.eviware.soapui.libs_0.4.1
[INFO] Building jar: /tmp/mvn-eclipse64720.tmp
[INFO]

[ERROR] FATAL ERROR
[INFO]

[INFO] null
[INFO]

[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.plugin.eclipse.MakeArtifactsMojo.processSingleFile(MakeArtifactsMojo.java:288)
at
org.apache.maven.plugin.eclipse.MakeArtifactsMojo.execute(MakeArtifactsMojo.java:199)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)

maven2 repository of eclipse jars

[Graham Leggett]

Hi all,

I have seen some effort scattered here and there for providing maven2
repositories containing the jars that make up the eclipse platform. It
would be great if an automated repository could be created that would keep
eclipse jars accessible to maven.

The eclipse:make-artifacts goal in the maven-eclipse-plugin is capable of
scanning an eclipse installation, and importing all the jars in that
installation into a maven2 repository.

Eclipse itself is capable of auto-updating itself from the command line,
without human or GUI intervention:
http://publib.boulder.ibm.com/infocenter/imshelp1/v3r0/index.jsp?topic=/com.ibm.cia.infocenter.doc/references/rupdatecommand.html

These two features together, with some scripting and a place to host the
repository, is in theory all that would be needed to make eclipse jars
automatically available to maven users.

Thoughts?

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] release maven-ear-plugin

[Graham Leggett]

On Mon, December 11, 2006 3:37 pm, Jason van Zyl wrote:

> You cannot start a vote unless you are a committer.

It does? I could not find anything like this at
http://www.apache.org/foundation/voting.html. Binding votes are cast by
PMC members as I understand (I am on the httpd PMC), but a call for a vote
can come from anyone.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] release maven-ear-plugin

[Graham Leggett]

On Mon, December 11, 2006 6:10 pm, Jason van Zyl wrote:

> Some who is not developing the code cannot call a vote. At least one
> that's going to actually be voted on. I can't walk into the httpd
> mailing list and ask for a release of httpd. Come on.

I am not aware of any barrier stopping anybody on the httpd list or any
ASF list asking for a release. Or to state this another way, how does a
community get developed if new community members are not allowed to
participate in the process?

I am also concerned about the idea that only "code developers" have the
right to express themselves within a project. There are many many valuable
contributions that can be made without code, from bug reporting, to
documentation, to helping users, to identifying usability problems in the
wild with feedback.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] release maven-ear-plugin

[Graham Leggett]

On Mon, December 11, 2006 7:12 pm, Jason van Zyl wrote:

> You didn't ask for a release, you tried to call a vote. Very
> different things.

Explain how these are different?

> That's an example of how it works and how
> you can participate. Do some work, get a say. It's pretty standard
> Apache stuff.

I believe that as a long time ASF member I understand how things work, and
again as an ASF member I am am expressing concern that your response to my
call for a vote was not in the spirit of community building. The ASF is
about community, not code.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] release maven-ear-plugin

[Graham Leggett]

Jason van Zyl wrote:

Asking for a vote means that people can make preparations and actually 
figure out what's going to be done for the next release. Create a 
roadmap, field help and plan toward making something release worthy. 
When all that is done, the work has been looked over and it is felt that 
all the issues for the release have been dealt with then you call a 
vote. When it's actually ready.


When I asked as the the status of the ear plugin last week, the answer 
was that it was pretty much ready. I asked for a vote, but none came - 
probably because people were busy this time of year, so being proactive 
and knowing the drill I called the vote for the release, a perfectly 
reasonable thing to do.


The reason for the call for a vote is that right now the snapshot docs 
for the plugins are currently live in the maven documentation tree. 
Fixing this either means taking the docs down, or simply making releases 
of the plugins in question. Making releases is a step forward IMHO and a 
far better solution than taking the docs down.


I am also a member, have been here for 6-7 years, helped many project 
migrate to the ASF, have volunteered more of my time, produced more code 
(probably should have documented it), and helped more people then a good 
majority at the ASF.


I'm sorry, I fail to see how "my contribution is bigger than theirs" 
could possibly contribute anything to this discussion.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: maven2 repository of eclipse jars

[Graham Leggett]

Carlos Sanchez wrote:


that sounds good and can be setup as if it were another mirror, the
important questions
who will volunteer to do it?
is enough people asking for them that it makes sense?


In theory, keeping such a repository up to date could be done from a 
zone, and it's not a problem for me to set up (having already figured 
out the details), but the repository itself contains Eclipse code - 
would ibiblio host a mirror of such a thing?


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [vote] release maven-ear-plugin

[Graham Leggett]

Brett Porter wrote:

I don't understand this. Is there a field in the documentation that is 
only available in the snapshot and not documented as such?


Yes (pointed this out originally last week) - for example: 
http://maven.apache.org/plugins/maven-ear-plugin/modules.html#harModule 
(only available in v2.3-SNAPSHOT) and 
http://maven.apache.org/plugins/maven-eclipse-plugin/make-artifacts-mojo.html 
(also only available in the snapshot).


These pages indicate last updated 7 and 8 November respectively - 
someone may have updated the site docs by accident.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

maven2 and NTLM

[Graham Leggett]

Hi all,

According to the docs, maven1 supported NTLM proxies. I cannot find
anything definitive to say whether NTLM proxies are supported in maven2
though.

In our case the ISA proxy also supports basic auth, but this also doesn't
work - I suspect the underlying proxy code implementation in maven wants
to use NTLM but hasn't been given the name of the domain by the maven
config, and so fails.

Can anyone confirm if this is the case?

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: The Future of the Release Process.

[Graham Leggett]

On Thu, December 14, 2006 1:46 am, Joakim Erdfelt wrote:

>   Disclaimer: I am not attempting to set policy, just to get discussion
> going,
>   document it, and work towards the ideal toolchain that
> make the
>   future of apache releases smooth, consistent, and resilient
>
> Desired End Goal:
>
>   This discussion will revolve around the apache process for official
>   releases of projects.

[snip lots and lots of barriers to release]

Although I can see the desire to enforce compliance on policy, I think
adopting barriers to release like this will cause the projects to just
never be released, making an already bad problem worse.

There is another showstopper to this: One of the key provisions of
releasing artifacts at the ASF is that a release cannot be vetoed. The
thinking is that our code in SVN should always be policy compliant,
meaning that a release at any time should never be a problem.

What will probably work a lot better is for compliance to be enforced at
the source level, and here a "compliance plugin" hooked into the test
phase can check for all the various things like license headers on files
etc as required by the project.

So rather than chase people around months after code was committed to
bring it into compliance, the developer of a plugin can get immediate
feedback while they are developing to say that files X, Y and Z are non
compliant and need to be fixed.

Extra points if the plugin can auto-fix some of the issues.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

maven-ear-plugin and dependencies

[Graham Leggett]

Hi all,

Using the v2.3-SNAPSHOT version of the ear plugin, I am struggling to get
the application.xml file built correctly.

Between maven1 and maven2, the ejb plugin lost it's ability to bundle
dependencies inside the ejb.

This means (as I understand it) that it's now up to the ear plugin to add
all the dependencies to the application.xml file.

However, it seems that the maven-ear-plugin does not have any documented
functionality to add dependencies to application.xml, except for
explicitly declaring dependencies using the jarModule tag.

This duplicates the dependency list, and removes all the power behind
transitive dependency management, which is supposed to handle dependencies
for you.

Is there a setting I am not seeing, or does the ear plugin have no
dependency management features at all?

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven-ear-plugin and dependencies

[Graham Leggett]

On Thu, December 14, 2006 9:05 pm, Stephane Nicoll wrote:

> This has been tackled a dozen of times and I am not sure it has
> anything to do with the EAR plugin, at least if we follow the spec. If
> I am wrong, please let me know.
>
> The valid way to bundle shared components/libs in a EAR is to define
> the Class-Path entry of the manifest in EJB module(s) using the
> component. It's certainly not by adding them in a  module entry
> in the application.xml even though some application servers support
> this (JBoss namely).
>
> The EAR plugin supports the APP-INF/lib weblogic's trick by using the
> defaultJarBundleDir setting though.
>
> So I wouldn't say the EAR plugin has no dependency management features
> at all, I don't even see the point actually :) Make sure that your
> classpath entries got generated on the EJB side and it will just run
> fine.

Ok, then I'll put it this way: it has no dependency management features
that are clearly enough documented :)

If you create an ejb using the default ejb configuration, and then you add
this ejb to an ear file again with a default configuration, maven goes
through all the motions and creates what looks like a valid ear file.

But this ear file refuses to load into Jboss (the dreaded NoClassDefFound
exception).

Is there a reason why a spec compliant ejb and ear can't be created by
default by the ejb and ear plugins? I'm asking from ignorance - I don't
have in depth knowledge of the internal structure of an ear file, that
being maven's job to worry about this stuff for me.

The only mention I can find about the classpath entry is a FAQ entry at
http://maven.apache.org/plugins/maven-ejb-plugin/faq.html, but this rather
cryptic explanation doesn't indicate why you might want to do this
(although it seems clear from your explanation that it is necessary), or
why this behaviour isn't the default behaviour for the plugin.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: downloading eclipse runtime binary or RCP delta pack

[Graham Leggett]

Bhupendra Bhardwaj wrote:


The maven repository doesn't have the eclipse swt plugins for all
platforms.  I have few questions, can those be answered please if possible-
- Can I download the eclipse runtime binary or any zip/tar from
http://download.eclipse.org/eclipse/downloads/drops/R-3.2.1-200609210945/.
If yes, then how?


I am currently in the process of trying to solve this problem.

Although the latest eclipse jars are not (yet) available in a maven 
repository, the 2.3-SNAPSHOT maven-eclipse-plugin has a goal 
eclipse:make-artifacts that, given a directory containing an eclipse 
installation, will import all the eclipse jars into your local 
repository, complete with dependency information. It works very well.


You can point the maven-eclipse-plugin at the deltapack, and those jars 
can be imported as well.



- how can I assemble the RCP for different platform using maven? Is it
profiles I need to use in assembling or there is some other or better way.


That is my next task - the maven-pde-plugin seems the most likely 
solution, however I have not yet found a way to produce an eclipse RCP 
app for multiple platforms using this method, yet.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: downloading eclipse runtime binary or RCP delta pack

[Graham Leggett]

On Mon, December 18, 2006 11:03 am, Bhupendra Bhardwaj wrote:

> "eclipse:make-artifacts" is a nice feature but it will work only if the
> person building and assembling the project has eclipse installed in his or
> her machine, which I think will not be the case as the RCP is one of the
> modules and not everybody will be working on it.

Not at all - we used eclipse:make-artifacts to create our own internal
maven repository for eclipse. It's something you only need to do once.

Previous to that we would often copy around the .m2/repository directory
from developer to developer, as it was the quickest way for changes to to
be propagated.

> For compilation purpose the win32 eclipse jars are availabe in maven (
> repo1.maven.org), so compilation is not a problem.

The eclipse jars in repo1.maven.org are over a year old, and only a small
subset of the eclipse jars are available. It's far safer in the long term
to create a complete and up to date repo of your own.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: downloading eclipse runtime binary or RCP delta pack

[Graham Leggett]

On Mon, December 18, 2006 4:59 pm, Daniel Kulp wrote:

> My can't someone on the Maven team run the plugin/script and put them up
> on
> repo1 someplace?   That's what I'm having a hard time understanding.
> People
> obviously want them published, what stopping them from being published?

The problem I saw posted recently about this was that once published, the
repository is cast in stone, including errors.

If this was published in a separate repository, with proper caveats
advertised ("this is beta", "this might change in future", whatever), this
would fix this problem.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: downloading eclipse runtime binary or RCP delta pack

[Graham Leggett]

On Tue, December 19, 2006 10:24 am, [EMAIL PROTECTED] wrote:

> =8*O I beg your pardon? I looked in JIRA but couldn't find a report about
> this. Is there? If not, I'd open one. ;-)
>
> The idea that you'll never have to fix a broken POM/JAR/whatever is just
> ridiculous. :-) As I understand it, the repo admins are just very
> reluctant to modify already published artefacts.

That's what I meant, yes.

As it turns out, someone has already published the full eclipse tree to
repo1, so all this is moot :)

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: downloading eclipse runtime binary or RCP delta pack

[Graham Leggett]

On Tue, December 19, 2006 5:15 pm, Bhupendra Bhardwaj wrote:

>> The most simple solution right now is probably to add
>> http://repo1.maven.org/eclipse/ to your list of repositories in
>> settings.xml.

> Not really. Because the solution I was looking for was to package my RCP
> app
> for all platforms and the repo1.maven.org/eclipse only has swt jar for
> win32
> platform.

And the solution to that is to point eclipse:make-artifacts at the eclipse
deltapack, and import those jars into the repository as well. This worked
for us.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven2 and NTLM

[Graham Leggett]

On Wed, December 20, 2006 1:27 pm, Steve Loughran wrote:

> "who is interested in working with me to come up with something that is
> broadly useful"?
>
> One troublespot with proxy code is testing. I know I cant test NTLM
> proxies, but do at least have access to an unauthenticated proxy-whether
> I want to or not

I can help - I have access to an authenticated NTLM proxy right now. I may
have patchy access to the net next week for the holiday, but after 1 Jan
things return to semi normal.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Some conceptual issues: building eclipse rcp with maven

[Graham Leggett]

Hi all,

I have been trying to investigate how practical it is to build eclipse
plugins using maven, and have run into some conceptual issues which are
not explained at all in any of the docs I have found.

So far, the pde-maven-plugin shows the most promise in building an eclipse
rcp application. Trouble is, the plugin docs include no explanation
whatsoever how dependencies are handled from the maven world to the
eclipse world.

Maven dependencies are specified in pom files, and maven will eventually
build a list of dependent jars, and make these available to the build.

What is the eclipse equivalent of dependencies? All docs I have read to
date suggest that all eclipse dependencies need to be deployed as plugins,
bundled into features. This implies that for every one of my 50 or so
dependencies, I have to somehow convert these jars into eclipse plugins.
This seems way wrong.

I have seen eclipse plugins containing other jars, which starts making
more sense. The trouble is that the pde-maven-plugin seems to contain no
mechanism to include maven dependency jars into an eclipse plugin, or if
this mechanism does exist, it is undocumented.

Can anyone shed more light on how this all works?

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Establish a list of emeritus committers

[Graham Leggett]

Kenney Westerhof wrote:


- these people should be send a direct e-mail notifying them so they
 know what's going on. If they've been unactive in such a long
 period it's higly likely that they don't follow the dev list anymore,
 and should they want to participate again they'd be in for a big surprise.


A definite +1. People may have shifted onto other projects, and may be 
back in the future.


- How do other projects deal with emeritus committers? Is this 
conforming to

 apache-wide standards?


I have not yet seen an attempt to make emeritus inactive committers on 
any of the other projects I have been involved with, though a better 
place to ask this would be on [EMAIL PROTECTED]


An attempt was made a while back to handle the issue of inactive 
members. There people were sent emails asking whether they would 
voluntarily like to be made emeritus, or whether they planned to 
participate again in the future. Only people who actively said "make us 
emeritus" were given emeritus status.


The issue of emeritus status is a delicate one, and needs to be handled 
diplomatically. A blanket removal of karma without notice should be 
avoided IMO.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Jboss client jars and maven

[Graham Leggett]

Hi all,

I am have a very strange interoperability problem between jars produced by
maven and jars produced by ant when it comes to JBoss.

JBoss supports the concept of java code running standalone accessing EJBs
in a JBoss container over a network. To do this you package up two files
into the META-INF directory of a jar file - application-client.xml and
jboss-client.xml - and deploy this client jar within your ear file to your
JBoss server.

We have an existing ant generated client jar that works fine in the ear
file. When we swap it with the same jar built by maven, Jboss refuses to
load the EJBs from the ear file, and behaves in a generally broken way,
but not enough to give us a real error message. Swap the ant created jar
back, and all returns back to normal. All other jars, from dependencies to
the ejb and ear file, are built using maven, and these work fine on
condition the ant built client jar is included.

The differences between the ant jar and the maven jar come down to the
entries inside MANIFEST.MF. The ant build has Ant-Version and Created-By,
while the maven version has Archiver-Version, Created-By, Built-By and
Build-JDK. The maven jar also has a "maven" directory containing the pom
file.

I don't yet know enough about all of this to reliably ascertain whether
this is a JBoss problem or a maven problem, my question is - has anyone
seen behaviour like this before?

Could the different attributes inside the MANIFEST.FM file affect things?
Could the presence of the "maven" directory and the copy of the pom file
in the jar upset JBoss in any way?

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

deploy:deploy-file target and DAV

[Graham Leggett]

Hi all,

As a test I have configured the deploy:deploy-file goal to deploy to a
WebDAV server. The login and ssl part works fine, but the attempt to PUT
the file fails with a 403 response code (but not because of auth failure
according to the logs).

It looks like the plugin is not making an attempt to create the
directories in the repository before trying to upload the file to the
repository, thus the failure:

[Tue Jan 30 13:45:57 2007] [debug] mod_auth_ldap.c(382): [client
172.18.132.82]
[7883] auth_ldap authenticate: accepting [EMAIL PROTECTED]
[Tue Jan 30 13:45:57 2007] [error] [client 172.18.132.82] Unable to PUT
new contents for /maven2/alchemy/test/0.0.0/test-0.0.0-win32.patch.  [403,
#0]
[Tue Jan 30 13:45:57 2007] [error] [client 172.18.132.82] (2)No such file
or directory: An error occurred while opening a resource.  [500, #0]

Has anyone got the deploy:deploy-file target to work with DAV before?

The command line is as follows, a "server" is defined correctly in
settings.xml:

Graham-Leggetts-Computer:~ minfrin$ mvn deploy:deploy-file
-Dfile=subversion-package-fix.patch
-Durl=https://alchemy.scmb.co.za/maven2 -DrepositoryId=alchemy.scmb.co.za
-DgroupId=alchemy -Dversion=0.0.0 -Dclassifier=win32 -DartifactId=test
-Dpackaging=patch

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: deploy:deploy-file target and DAV

[Graham Leggett]

On Tue, January 30, 2007 1:55 pm, Aaron Digulla wrote:

> Have you tried with 1.0-beta-2 of wagon-webdav? This solved some
> problems for me.

Not yet - I am trying to do this without a pom file (the artifacts are
ultimately matlab generated). Seems creating a pom is the way to go. Will
try it and get back to you, thank you for the response!

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: deploy:deploy-file target and DAV

[Graham Leggett]

On Tue, January 30, 2007 1:55 pm, Aaron Digulla wrote:

> Have you tried with 1.0-beta-2 of wagon-webdav? This solved some
> problems for me.

Dumb question... how do you override the dependency of a plugin?

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: deploy:deploy-file target and DAV

[Graham Leggett]

On Tue, January 30, 2007 1:55 pm, Aaron Digulla wrote:

> Have you tried with 1.0-beta-2 of wagon-webdav? This solved some
> problems for me.

Added the 1.0-beta-2 of wagon-webdav like this:

  

  
org.apache.maven.wagon
wagon-webdav
1.0-beta-2
  

...
  

And no luck - it fails the same way.

Analysing the logs, I can't see how the plugin in it's current form could
work at all - the logs show no attempt to detect whether the directories
already exist, nor do they show any attempt to create directories - the
upload is therefore doomed to fail.

Has anyone got any ideas?

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

deploy:deploy-file target and DAV

[Graham Leggett]

Hi all,

As a test I have configured the maven deploy:deploy-file goal to deploy to a
WebDAV server. The login and ssl part works fine, but the attempt to PUT
the file fails with a 403 response code (but not because of auth failure
according to the logs).

It looks like the plugin is not making an attempt to create the
directories in the repository before trying to upload the file to the
repository, thus the failure:

[Tue Jan 30 13:45:57 2007] [debug] mod_auth_ldap.c(382): [client
172.18.132.82]
[7883] auth_ldap authenticate: accepting [EMAIL PROTECTED]
[Tue Jan 30 13:45:57 2007] [error] [client 172.18.132.82] Unable to PUT
new contents for /maven2/alchemy/test/0.0.0/test-0.0.0-win32.patch.  [403,
#0]
[Tue Jan 30 13:45:57 2007] [error] [client 172.18.132.82] (2)No such file
or directory: An error occurred while opening a resource.  [500, #0]

Has anyone got the deploy:deploy-file target to work with DAV before?

The command line is as follows, a "server" is defined correctly in
settings.xml:

Graham-Leggetts-Computer:~ minfrin$ mvn deploy:deploy-file
-Dfile=subversion-package-fix.patch
-Durl=https://alchemy.scmb.co.za/maven2 -DrepositoryId=alchemy.scmb.co.za
-DgroupId=alchemy -Dversion=0.0.0 -Dclassifier=win32 -DartifactId=test
-Dpackaging=patch

The [EMAIL PROTECTED] list suggested I try v1.0-beta-2 of wagon-webdav, but this
has had no effect.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: deploy:deploy-file target and DAV

[Graham Leggett]

On Tue, January 30, 2007 3:09 pm, Aaron Digulla wrote:

> Which version of the maven-deploy-plugin do you use? Have you tried 2.3?

Yes (both natively as it's the latest release, and explicitly by adding it
to the pom) - made no difference.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: deploy:deploy-file target and DAV

[Graham Leggett]

On Tue, January 30, 2007 3:08 pm, Aaron Digulla wrote:

> You do see the correct version in the output of Maven?

I saw maven download the v1.0-beta-2 jars and dependencies.

> The simple workaround would be to create the directories manually
> until the bug is fixed.

Unfortunately the end result of our efforts is to automate the deployment
process. If people have to create directories manually, then they might as
well upload the artifact manually.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: deploy:deploy-file target and DAV

[Graham Leggett]

On Tue, January 30, 2007 3:08 pm, Aaron Digulla wrote:

> The simple workaround would be to create the directories manually
> until the bug is fixed.

I created each directory manually, up to and including the version number.

Once all the directories existed, the return code from wagon-webdav was
"201 Created" (meaning file successfully uploaded), followed by "204 No
Content" (meaning file successfully replaced).

In both cases, the deploy plugin treated these 2xx response codes
incorrectly as errors, like so:

[INFO] [deploy:deploy-file]
Uploading:
https://alchemy.scmb.co.za/maven2/alchemy/test/0.0.0/test-0.0.0-win32.patch
703b uploaded
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error deploying artifact: Unable to transfer file.
HttpURLConnection returned the response code: 204

Can anyone confirm whether this plugin has ever worked for them, and if
so, what DAV server is being used? I am using httpd v2.0.52 as shipped
default with RHEL4.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Confirm: Webdav and SSL works

[Graham Leggett]

Hi all,

In the source file at
https://svn.apache.org/repos/asf/maven/wagon/tags/wagon-1.0-beta-2/wagon-providers/wagon-webdav/src/main/java/org/apache/maven/wagon/providers/webdav/WebDavWagon.java,
the following comment is present:

TODO: webdav https server is not tested

I have tested the wagon against an SSL enabled DAV webserver and SSL works
- on condition that the CA certificate used to sign the DAV server's
certificate is installed in the JDK's default cacerts keystore.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: deploy:deploy-file target and DAV

[Graham Leggett]

On Tue, January 30, 2007 3:49 pm, Aaron Digulla wrote:

> I'm using wagon-webdav 1.0-beta-2 with maven-deploy-plugin 2.3
> together with Archiva (SVN SNAPSHOT build). Before 1.0-beta-2/2.3,
> this was pretty unstable (every 3rd deploy would fail) but now, it
> works pretty good (even though I still have the occasional hickup).

Digging some more into the stacktraces, it seems that
wagon-http-lightweight-1.0-alpha-6 (as provided by the maven v2.0.4
tarball) is handling the put requests, and not the webdav wagon at all.

I am using the URL prefix https:// to deploy to the repository, is this
the correct prefix?

It looks like both the DAV wagon and the lightweight http wagon are
responding to the same URL schemes - should I remove the lightweight http
wagon?

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Activating profiles based on OS

[Graham Leggett]

Hi all,

According to the docs for configuring profiles at
http://maven.apache.org/settings.html#Profiles, it is apparently possible
to activate a profile based on OS parameters.

The example given activates when Windows is present:


  Windows XP
  Windows
  x86
  5.1.2600


I cannot find a definitive list anywhere obvious of possible OS values
that you can detect on, is there some way of finding out these values for
Linux, Solaris and Macosx?

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Activating profiles based on OS doesn't seem to work right

[Graham Leggett]

Hi all,

I've been trying to use profile activation based on OS to work around 
maven's lack of support for exposing the OS family (you can test against 
the current OS family, you just cannot find out what the current OS 
family is using ${maven.os.family} or some equivalent, or it least it 
seems that way from the users list).


For example, the following profile doesn't match anything on MacosX:


  activate-mac
  
macosx
${os.arch}
  
  

  Mac OS X

  


The following variation does detect MacosX (using family instead of name):


  activate-mac
  
macosx
${os.arch}
  
  

  mac

  

...
  
ppc
macosx
  

But, as soon as you try and detect Linux and MacosX side by side, Linux 
is detected on MacosX, instead of MacOSX:



  activate-linux
  
linux
${os.arch}
  
  

  

  


  activate-mac
  
macosx
${os.arch}
  
  

  mac

  

...
  
linux
ppc
  

Similar weirdness happens when you try and mix family linux with family 
unix - linux is reported on solaris, instead of unix.


The values are being tested using mvn help:effective-pom.

The problem I am trying to solve is to obtain a filename-friendly 
version of ${os.name} ("Windows XP" and "Mac OS X" contain spaces and 
are therefore not filename friendly), to be used as a classifier.


Does anyone know what the canonical way to do this is?

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Activating profiles based on OS doesn't seem to work right

[Graham Leggett]

On Wed, February 7, 2007 3:46 am, Franz Allan Valencia See wrote:

> I don't know why this should not work ( and I don't have a Mac to try
> it on). Try entering the os name all in small caps ( i.e. "mac os x"
> ).

Small case works, even though when you print the value of ${os.name} the
operating system is listed capitalised, like so: "Mac OS X".

I added it to JIRA like so:

http://jira.codehaus.org/browse/MNG-2814

> I don't know why mac is not detected, but linux gets detected (
> assuming by "" you meant "linux"
> ) because linux is an unknown os family to maven2. And unknown os
> family always gets activated ( I have just filed an issue for this.
> see [1] )

Ok - it seems I am being bitten by the unknown os family gets activated
problem as well, which is why "linux" keeps winning.

I had already looked at the list at [2], and could have sworn linux was on
that list (on second look it isn't, you're quite correct). Need more
sleep.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Svn failure during release:perform

[Graham Leggett]

Hi all,

I have been trying to run a release:perform on a Windows XP machine 
running maven v2.0.4, and have been getting the subversion error below.


Running both the subversion command line client (v1.4.2) update, and 
tortoisesvn's (latest version) update work fine, it's only when maven 
attempts to resume the checkout does the checkout below fail.


The same release:perform works fine under Solaris and Macosx.

The error is as follows:

Provider message:
The svn command failed.
Command output:
svn: Your .svn/tmp directory may be missing or corrupt; run 'svn 
cleanup' and try again
svn: Can't open file 
'checkout\alchemy-quant\src\matlabdevelopment\Toolbox\CreditDerivatives\ParRecovHazardRateTreeModel\UnexposedCode\.svn\tmp\text-base\GetCalibratedOneFactorHullWhiteHazardRateTreeFromCdsSpreadsRP.m.svn-base': 
The system cannot find the path specified.


This error is usually caused by two versions of a file that are 
identically named when compared case insensitively, though that isn't 
the case here (I checked that first).


Anyone have any ideas what to look for?

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Svn failure during release:perform

[Graham Leggett]

Dan Tran wrote:


you hit the limit of windows path which is 256 chars :-)

Try to set your checkout directory to the shorttest and see if it helps 
( ie

c:/t )


What confuses me is that both the native svn command line client, and 
tortoisesvn, are capable of checking this same directory out without a 
problem (as in find the directory containing the half-checked-out 
directory throwing the error, and say "svn cleanup" followed by "svn 
update", works fine).


Is this directory length limit a Java thing or a Windows thing?

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Svn failure during release:perform

[Graham Leggett]

On Sat, February 17, 2007 6:41 pm, Dan Tran wrote:

> in your msg
>
> checkout\alchemy-quant\src\matlabdevelopment\Toolbox\CreditDerivatives\ParRecovHazardRateTreeModel\UnexposedCode\.svn\tmp\text-base\GetCalibratedOneFactorHullWhiteHazardRateTreeFromCdsSpreadsRP.m.svn-base
>
> I has 205 not counting the parent dir oabove 'checkout/'
>
> so you mean you are able to go into parent of the checkout and issue the
> same command and it works? no clue why it works
>
> How many chars are in your checkout's parent directory path?
>
> 256 is windows limitation not java.

Been able to confirm some more on this.

Using the native svn command line client, I am able to check out the
entire tagged tree without error, both in a "deep" directory, and a
"shallow" directory (c:\tmp).

Using release:perform in a "deep" directory, the checkout bombs out with
the error already posted.

Using release:perform in a "shallow" directory, the checkout bombs out
with a segfault on one machine, and a silent failure on the other machine:

  The instruction at "0x6eed0f67" referenced memory at "0x010c1800" The
memory could not be "read".

Is there some kind of resource limit imposed on svn when it is spawned by
the maven plugin?

Is there a way to reveal the command line being passed to svn when the
plugin runs?

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Strange inclusion bug with the jar plugin

[Graham Leggett]

Hi all,

I asked on the user list whether I was doing this correctly, but got no 
response - in the mean time this is looking like a bug.


I have a jar file, attached to the lifecycle being the compiling of some 
C++ code into target/build, which works fine.


I need to embed the C++ library inside the jar file, so I add the 
following resource:


  
${project.build.directory}/build

  **/*.dll
  **/*.so
  **/*.dylib

  

And nothing happens - the C++ library is present, but ignored and never 
ends up in the jar file.


Running mvn -X install doesn't help, as the jar plugin doesn't output 
any relevant debug level information, like the directories it considers 
for inclusion.


Can anyone confirm whether this is supposed to work?

I am using maven v2.0.4.

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Assembly plugin: breakage if a dependency includes a classifier

[Graham Leggett]

Hi all,

I have a set of modules that I need to assemble into a directory.

These modules depend on some platform specific matlab ctf and jar files
that have been published into the maven repository with a classifier
giving the platform, like so:

alchemy-quant-4.0.5-macosx.jar
alchemy-quant-4.0.5-macosx.ctf

To start with a working config and move on from there, I copied the
jar-with-dependencies assembly into my project and made it valid, then I
turned off the dependency unpack behaviour - in other words, I expect to
end up with some dependencies in a directory.

When I run mvn assembly:assembly and unpack the result, I end up with an
assembly containing this:

-rw-r--r--1 minfrin  minfrin  15125 Mar  1 17:35 -macosx
drwxr-xr-x7 minfrin  minfrin238 Mar  8 18:30 .
drwxr-xr-x7 minfrin  minfrin238 Mar  8 18:29 ..
drwxr-xr-x3 minfrin  minfrin102 Mar  8 18:28 META-INF
drwxr-xr-x   17 minfrin  minfrin578 Mar  8 18:21 alchemy
-rw-r--r--1 minfrin  minfrin  11306 Feb 28 17:36 log4j.properties

The file "-macosx" represents the alchemy-quant-4.0.5-macosx.jar file.

Interestingly enough, building the same thing on Windows results in a
directory called -windows rather than a file, but otherwise the effect is
the same.

Can anyone confirm whether the assembly plugin has ever worked on a
project that depended on projects containing classifiers?

The dependency is defined like this:


  alchemy
  alchemy-quant
  4.0.5
  ${os-platform}



  alchemy
  alchemy-quant
  4.0.4
  ctf
  ${os-platform}


Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

release:perform and classifier breakage

[Graham Leggett]

Hi all,

I am trying to do a release:perform on a project that creates a jar with a
classifier.

For some reason, as part of release:perform, install:install is called,
and when install:install is called _without_ being part of the build
lifecycle, it fails with the error below.

I tried configuring the install plugin to have a classifier, but to no avail.

I also tried setting the finalName to the name+version+classifier, but
also to no avail:

   ${artifactId}-${version}-${os-platform}-${os-arch}

Has anyone seen release:perform work with a classifier present?

[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:jar {execution: attach-sources}]
[INFO] Building jar:
/udd001/app/alchemy/development/native-new/trunk/target/checkout/alchemy-cdo/target/alchemy-cdo-4.0.6-sources.jar
[INFO] [install:install]
[INFO] No primary artifact to install, installing attached artifacts
instead.
[INFO] Installing
/udd001/app/alchemy/development/native-new/trunk/target/checkout/alchemy-cdo/target/alchemy-cdo-4.0.6-linux-Linux
amd64.jar to
/udd001/app/alchemy/.m2/repository/alchemy/alchemy-cdo/4.0.6/alchemy-cdo-4.0.6-linux-Linux
amd64.jar
[INFO] Installing
/udd001/app/alchemy/development/native-new/trunk/target/checkout/alchemy-cdo/target/alchemy-cdo-4.0.6-sources.jar
to
/udd001/app/alchemy/.m2/repository/alchemy/alchemy-cdo/4.0.6/alchemy-cdo-4.0.6-sources.jar
[INFO] [deploy:deploy]
altDeploymentRepository = null
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error deploying artifact:
/udd001/app/alchemy/development/native-new/trunk/target/checkout/alchemy-cdo/target/classes
(Is a directory)

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: release:perform and classifier breakage

[Graham Leggett]

On Mon, March 12, 2007 4:34 pm, Graham Leggett wrote:

> Has anyone seen release:perform work with a classifier present?

I have managed to narrow this down to the deploy plugin. It seems the
deploy plugin cannot deploy a jar with a classifier. The stacktrace is
below.

[INFO] [jar:jar]
[INFO] Building jar:
/Users/minfrin/src/standard/alchemy/development/native/trunk/alchemy-cdo/target/alchemy-cdo-4.0.6-SNAPSHOT-macosx-ppc.jar
[INFO] [build-helper:attach-artifact {execution: attach-artifacts}]
[INFO] [install:install]
[INFO] No primary artifact to install, installing attached artifacts instead.
[INFO] Installing
/Users/minfrin/src/standard/alchemy/development/native/trunk/alchemy-cdo/target/alchemy-cdo-4.0.6-SNAPSHOT-macosx-ppc.jar
to
/Users/minfrin/.m2/repository/alchemy/alchemy-cdo/4.0.6-SNAPSHOT/alchemy-cdo-4.0.6-SNAPSHOT-macosx-ppc.jar
[INFO] Installing
/Users/minfrin/src/standard/alchemy/development/native/trunk/alchemy-cdo/target/alchemy-cdo-4.0.6-SNAPSHOT-macosx-ppc.jar
to
/Users/minfrin/.m2/repository/alchemy/alchemy-cdo/4.0.6-SNAPSHOT/alchemy-cdo-4.0.6-SNAPSHOT-macosx-ppc.jar
[INFO] [deploy:deploy]
altDeploymentRepository = null
[INFO] Retrieving previous build number from alchemy.scmb.co.za
WAGON_VERSION: 1.0-beta-2
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error deploying artifact:
/Users/minfrin/src/standard/alchemy/development/native/trunk/alchemy-cdo/target/classes
(No such file or directory)

[INFO]

[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error deploying
artifact:
/Users/minfrin/src/standard/alchemy/development/native/trunk/alchemy-cdo/target/classes
(No such file or directory)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error deploying
artifact:
/Users/minfrin/src/standard/alchemy/development/native/trunk/alchemy-cdo/target/classes
(No such file or directory)
at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:174)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
... 16 more
Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
Error deploying artifact:
/Users/minfrin/src/standard/alchemy/development/native/trunk/alchemy-cdo/target/classes
(No such file or directory)
at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:95)
at
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:162)
... 18 more
Caused by: java.io.FileNotFoundException:
/Users/minfrin/src/standard/alchemy/development/native/trunk/alchemy-cdo/target/classes
(No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:106)
at org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:820)
at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:74)
... 19 more

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

maven ignores resources phase

[Graham Leggett]

Hi all,

I have a pom file, that using ant generates a C++ library, which is then
packaged as a jar.

The ant build is attached to the generate-resources phase, and when you
run "mvn resources:resources" the library is correctly copied to
target/classes.

However: when you run "mvn install", the resources, although generated,
are ignored by the resources plugin, or the resources phase is just not
being run. The result is an empty jar file.

Are there circumstances where phases are skipped?

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven ignores resources phase

[Graham Leggett]

On Tue, March 13, 2007 7:44 pm, Brett Porter wrote:

> Sounds like a great question to ask [EMAIL PROTECTED] :)
>
> (and with over 3 times as many subscribers, your odds of an answer
> are much, much better)

I have posted a number of questions to the users lists recently, none of
which have received any replies.

Those, like this query, were very technical in nature, and it seems the
dev list is more qualified to answer them.

I am trying to unravel a number of bugs in maven when used in conjunction
with classifiers, and don't know enough of the internals to be able to
distinguish between "it works that way by design" or "it's broken".

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Test failure on trunk

[Graham Leggett]

Hi all,

While trying to build trunk of continuum, I am getting the following 
test failure on MacosX v10.4:


---
Test set: 
org.apache.maven.continuum.buildcontroller.DefaultBuildControllerTest

---
Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 255.852 
sec <<<

FAILURE!
testWithDependencyChanges(org.apache.maven.continuum.buildcontroller.DefaultBuil
dControllerTest)  Time elapsed: 79.372 sec  <<< ERROR!
java.lang.OutOfMemoryError: Java heap space

Not sure exactly where the JVM should be given more memory, is this a 
maven problem or a continuum problem?


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Test failure on trunk

[Graham Leggett]

Emmanuel Venisse wrote:


jdk version?


Latest MacOSX version, jdk v1.5.0_07-164.

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Test failure on trunk

[Graham Leggett]

Emmanuel Venisse wrote:


how many memory is allocated to the build? Normally the default is enough.


No idea - checked out a pristine copy of trunk as of an hour or two ago, 
and did an mvn install.


Is there somewhere where memory allocations are set, perhaps in a pom file?

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Test failure on trunk

[Graham Leggett]

Jesse McConnell wrote:


most people I know just add the following to their environment variables

MAVEN_OPTS=-Xmx512m


It shouldn't be necessary to have to patch your environment to work 
around bugs in unit tests, if the tests need 512MB of RAM, then the 
surefire plugin should be configured to allocate 512MB of RAM.


+1 to this:


>
>  org.apache.maven.plugins
>  maven-surefire-plugin
>  
>-Xmx512m
>  
>


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

v1.1 alpha 1 and tomcat / derby

[Graham Leggett]

Hi all,

I am having a little trouble reconfiguring tomcat to allow the war version
of continuum v1.1 alpha1 to connect to two derby databases.

I am getting the cryptic error:

org.jpox.exceptions.ConnectionFactoryNotFoundException: Connection Factory
"java:comp/env/jdbc/continuum" not found

I have configured GlobalNamingResources inside tomcat's server.xml as
follows:









  
maxWait
5000
  
  
maxActive
4
  
  
url

jdbc:derby:/udd001/app/alchemy/continuum/derby/users;create=true
  
  
driverClassName
org.apache.derby.jdbc.EmbeddedDriver
  
  
maxIdle
2
  




  
maxWait
5000
  
  
maxActive
4
  
  
url

jdbc:derby:/udd001/app/alchemy/continuum/derby/continuum;create=true
  
  
driverClassName
org.apache.derby.jdbc.EmbeddedDriver
  
  
maxIdle
2
  


The Default context is defined like so:

  



  

I can't see anything obviously wrong, does this mean anything to anybody?

Regards,
Graham
--

Re: Maven Release Plugin seems to run "clean verify" and miss out on install for aggregate projects

[Graham Leggett]

On Tue, June 5, 2007 9:06 pm, Brett Porter wrote:

> Right. The reason for not choosing to install by default is that you
> end up with a "release" in your local repository which is not the
> final one.

We've run into this problem as well - the version being tested, as far as
I am aware, is the SNAPSHOT version, meaning that at the end of this, an
up to date build of snapshot will be included in the local repository,
which is perfectly reasonable.

The workaround for us to release aggregated projects is like this:

mvn install release:prepare

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven Release Plugin seems to run "clean verify" and miss out on install for aggregate projects

[Graham Leggett]

On Wed, June 6, 2007 4:50 pm, Mark Donszelmann wrote:

>> The workaround for us to release aggregated projects is like this:
>>
>> mvn install release:prepare
>>
> but this would do the install w/o the poms being changed from 3.3-
> SNAPSHOT to 3.3,
> so this would not help.

And yet it does help.

I suspect that in "aggregated mode" the versions are not changed, but the
install is not done, it only goes as far as "integration-test". If the
versions were changed to 3.3 before running the aggregated build, the
aggregated build would always fail due to missing artifacts, and this
doesn't happen in practise.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven Release Plugin seems to run "clean verify" and miss out on install for aggregate projects

[Graham Leggett]

On Wed, June 6, 2007 5:25 pm, Mark Donszelmann wrote:

> well, as far as I can conclude, an aggregated build will calculate
> the order in which to generate (and install) the artifacts, so that
> any module dependent on them is run later than the one generating
> them.

That won't matter. If you don't run the install step, then artifact A,
required by artifact B, won't be available to artifact B even though you
built (but didn't install) A - and your build of artifact B will fail.

If the build does succeed, it will be by accident - you'll be relying on
some previous invocation of mvn install that build artifact A.

> I am still confused though about your command:
>
> mvn install release:prepare
>
> will just execute these in order, so the poms would not have
> been changed.
>
> Max suggests to use -DpreparationalGoals="clean install"
> which would change the goals as part of the release:prepare.

I will try that the next time we do a release, which should be in the next
day or two.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problems with release:prepare

[Graham Leggett]

On Fri, June 8, 2007 12:16 pm, David Moss wrote:

> [INFO] Executing: svn --username username --password *
> --non-interactive
> copy --file C:\DOCUME~1\DAVID~1.MOS\LOCALS~1\T
> emp\maven-scm-403689689.commit . svn://SERVER001/tags/product-4.0

> The svn tag command failed.
> Command output:
> svn: Commit failed (details follow):
> svn: Source url 'svn://server001/trunk/product' is from different
> repository

This seems to be a subversion problem, as the error message is from
subversion.

Another potential issue is the SERVER001 compared with server001, it's
quite possible svn is treating these as two different servers.

Always be consistent with your naming.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven Release Plugin seems to run "clean verify" and miss out on install for aggregate projects

[Graham Leggett]

On Fri, June 8, 2007 1:57 pm, Emmanuel Venisse wrote:

> If you want to install artifacts in your local repo during the prepare
> process and don't want to use 'clean verify' goals, you can configure
> preparationGoals parameter on the prepare mojo
> (http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html)

This remains a workaround though.

Without this step, it is not possible to run release:prepare on an
aggregated project and expect it to always work.

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: prepare to release eclipse 2.4

[Graham Leggett]

Arnaud HERITIER wrote:


I would like to add that I have often some problems to run tests for this
plugin on windows.
Am I the only one to have this behaviour ?


I've had problems with tests that fail if there is no direct internet 
access from the machine running the test.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Apache Portable Runtime artifacts

[Graham Leggett]

Alan D. Cabrera wrote:

I'm not sure that we need to choose one over the other.  Let me ask you 
this, why would we need fine grained detail such as  "i386 vs. i586 vs. 
i686"?  Is that really necessary?


It is, because code compiled for i686 won't run on an i386, and code 
written for i386 may not run as effectively as code for i686. One 
shouldn't make arbitrary restrictions on how specific the platform can be.


I'm not sure why APR would allow such a system dependancy.  APR is 
supposed to make application developers' lives easier.  Why would I have 
to worry about libuuid1 missing?  I'm new to APR and am getting my head 
around what it will and will not do for me.


A bit of history on APR and why it exists.

Way back when, when people tried to make Apache httpd portable to many 
platforms, the httpd code started getting filled up with endless #ifdefs 
that said "if this system do this, if that system do that".


To try and return some sanity, an effort was made to herd together all 
the non portable code in httpd into one single library. That library 
would offer some portable concepts like (for example) an apr_socket_t 
instead of an integer socket, and you would not have to care what 
platform you were on any more, you could just use sockets and take it 
for granted that they would "just work".


The library that resulted is APR.

Like the JVM itself, APR tries very hard to be portable across 
platforms, and to do this, it needs to know how that particular platform 
works so you don't have to.


APR makes your life easier because all you need to do is write code that 
depends on APR, and (within reason) you no longer have to care exactly 
how the particular functionality you are using works on that platform. 
Sockets work differently on Windows? You don't have to care.


The problem is that APR itself *does* have to care how the system works, 
and about details like libraries that may or may not be installed, so 
anybody wanting to package APR into a bundle is going to have to worry 
about these issues.


Imagine if you had to try and package up the JVM and include it in a 
maven repo, the problems you would face there are similar to the APR case.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Apache Portable Runtime artifacts

[Graham Leggett]

Alan D. Cabrera wrote:


I was thinking that the artifact name could be

apr--

e.g. apr-linux-x86_64.   Or we can have a more general

apr---

where configuration is a token that represents a particular 
configuration of options, e.g. apr-msdos-8086-aztecc.


I don't use the apr-util code.  Can you explain what extra dependencies 
there are?


APR is typically installed at the system level, as a JVM would be, and 
being installed at a system level it would have a number of system 
dependencies installed along with it, some of which are optional.


In order to better understand the solution to this, can you explain the 
problem you are trying to solve?


Am I correct in assuming that you would like to access APR from Java 
(like tomcat does)?


If this is correct, it may make more sense to deploy the JNI bindings 
for APR into the maven repo, and then have those bindings depend on the 
system installed version of APR.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Apache Portable Runtime artifacts

[Graham Leggett]

Alan D. Cabrera wrote:

You bring up a good point in that it might be a good idea to describe 
the target deployments.  I'm sure that the APR team lives in a different 
universe than I.  You probably have to make sure that the code is 
general enough to run on my son's bluetooth enabled talking giraffe as 
well as stock Linux and Windows Vista boxes.  I'm sure the combinatorial 
space that you guys have to deal with is boggling.


I think in this case, my case, we only need to worry about a few stock 
configurations, e.g. Linux and Windows.  For me that would handle 99.9% 
of my universe.  More exotic configurations can use the naming 
conventions that we are currently working out and publish on an as 
needed basis; I don't anticipate this happening often.


To give some more color to what I want to do, I want to make OSGi 
bundles for APR.  For example, I need access to raw network sockets.  I 
don't want downstream users of my bundles to have to stitch by hand 
build runtime libraries to get my stuff to work.  In my narrow world 
it's inconvenient and, I believe, unnecessary.


Hmmm...

I think there are potentially two scenarios to be considered, the first 
where a system installed APR is already present, and the second is where 
APR is either not present at all, or not the version you want to run.


Potentially what might work is to have versions of APR that are 
statically built, and then bundled into OSGi. Being static, there would 
be few/no dependencies on the underlying system.


Another option is to include a stub bundle that refers to a system 
installed copy of APR. The stub bundle might be smart enough to detect 
when the system copy of APR is either missing, or not within the 
tolerated version range.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Apache Portable Runtime artifacts

[Graham Leggett]

Alan D. Cabrera wrote:

I think that there's something to be said about using the libraries that 
are bundled into OSGi rather than using libraries whose provenance is 
unknown.


In the Java world that might be true where one binary can be reasonably 
expected to work anywhere, but native libraries don't have this luxury.


APR is like the JVM itself, the best JVM is the system installed one, 
and the same can be said for APR.


Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature

Continuum v1.0.3...?

[Graham Leggett]

Hi all,

Is this ready for release yet? I saw voting, but no final conclusion.

I am about to install a copy of v1.0.2, and was hoping to put in v1.0.3
instead if possible.

Regards,
Graham
--

multiproject: The filename, directory name, or volume label syntax is incorrect

[Graham Leggett]

Hi all,

I am trying to build a multiproject under WinXP, but I am getting the
error below in the maven:reactor tag in the multiproject plugin. This same
project works 100% under MacOSX.

Using -e and -X, it reveals that the real error is "The filename,
directory name, or volume label syntax is incorrect". Unfortunately the
person writing the code didn't feel the end user would ever be interested
in _which_ file is incorrect, and so I am stuck. :(

Is there any way (apart from the -e and -X flags) for maven to reveal what
it resolved the maven:reactor tag to? Or an I doomed to install maven
under eclipse and step through it in a debugger?

  

The error when run looks like this:

C:\Java\continuum-1.0.3-20060414-bin\continuum-1.0.3-SNAPSHOT\apps\continuum\wor
king-directory\10>maven multiproject:clean multiproject:install
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

build:start:

multiproject:clean:
multiproject:projects-init:
[echo] Gathering project list
Starting the reactor...

BUILD FAILED
File..
C:\WINNT\profiles\leggettg\.maven\cache\maven-multiproject-plugin-1.3
.1\plugin.jelly
Element... maven:reactor
Line.. 63
Column 9
Error reading XML or initializing
Total time: 2 seconds
Finished at: Mon Apr 24 14:40:37 CAT 2006

Regards,
Graham
--



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]