Skip JXR ignored with 3.0.0

[Jörg Schaible]

Hi,

did someone manage to skip the JXR report for a specific module? 
According the documentation, you should simply configure skip to true. 
Looking at the code (https://maven.apache.org/jxr/maven-jxr-plugin/xref/
org/apache/maven/plugin/jxr/AbstractJxrReport.html#AbstractJxrReport), it 
should print the INFO line "Skipping JXR."

However, the flag is simply ignored whether I configure it in the 
reportSet section or the plugin level (checked with help:effective-pom). 
The forked generate-source lifecycle is always executed, the INFO line 
shows never up.

It seems the @Execute annotation will not call the execute or 
executeReport methods or will simply overwrite the skip flag. Does 
someone have a clue?

Regards,
Jörg


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

Re: Working with branches related to issue - Simplyfying work Part II

[Jörg Schaible]

Hi Karl-Heinz,

Am Mon, 30 Jul 2018 20:21:13 +0200 schrieb Karl Heinz Marbaise:

> Hi,
> 
> I have finished my write up about my current working scripts to make my
> life easier...
> 
> If someone is interested in take a look at:
> 
> https://blog.soebes.de/blog/2018/07/30/automate-it-part-ii/
> 
> suggestions/ideas are always welcome...

An invaluable source of processing XML files is the xmlstarlet package 
(typically installed as /usr/bin/xml), e.g. for extracting the URL for 
the issues.

Example: I have a short bash script to generate recursively minimal 
Eclipse project files for packaging types that are ignored by the maven-
eclipse-plugin:

== %< 
#!/bin/sh

packaging=pom
if [ "$1" = "-p" ]; then
shift
packaging=$1
shift
fi

if [ $# -lt 1 ]; then 
echo "Usage ${0##*/} [-p packaging] dir ..."
else
idx=0
poms=( "$@" )
while [ $idx -lt ${#poms[@]} ]; do
pom=${poms[$idx]}/pom.xml
path=${pom%/*}
let idx=$idx+1
if [ -f "$pom" ]; then
modules=`xml sel -N pom=$XMLNS_POM -t -m pom:project -m 
pom:modules -v pom:module $pom`
if [ -n "$modules" ]; then
for module in ${modules[*]}; do
poms+=( $path/$module )
done
else
if [ "$packaging" = "`xml sel -N \"pom=$XMLNS_POM" -t -m 
pom:project -v pom:packaging \"$pom\"`" ]; then
if [ ! -f "$path"/.project ]; then
name=`xml sel -N "pom=$XMLNS_POM" -t -m 
pom:project -v pom:artifactId "$pom"`
echo ''"$name"'' > "$path"/.project && echo "$path/.project"
fi
fi
fi
fi
done
fi
== %< 

The variable XMLNS_POM is declared in my .bashrc:

export XMLNS_POM="http://maven.apache.org/POM/4.0.0;

If you look at the script I use xmlstarlet to extract the modules, the 
project name and to compare the packaging type. 

Cheers,
Jörg


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

Re: Build vs Consumer POM study

[Jörg Schaible]

Hi Mirko,

On Tue, 17 Apr 2018 04:44:57 + Mirko Friedenhagen wrote:

> Hello Jörg,
> 
> I understand your problem, however this is quite specific. AFAIK
> currently profiles are *not* evaluated while resolving imported
> dependencies, only those inherited, so this would be a very drastic
> change.

Well, the import scope is special anyway, but I agree, that dependency 
resolution should not make a 
difference if you use this compared to a "normal" (transitive) dependency.

> For your eclipse example: maybe put OS specific stuff in modules and
> mark them as optional while importing?

If SWT is not optional, your user's might be quite surprised if it had been 
declared optional. But I do not like 
this situation also.

Cheers,
Jörg


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

Re: Build vs Consumer POM study

[Jörg Schaible]

On Mon, 16 Apr 2018 21:46:21 + Mirko Friedenhagen wrote:

> Hello,
> 
> I do not see why profiles should be part of the consumer pom.

If you're building a library based on SWT you have:

- org.eclipse.swt:org.eclipse.swt.win32.win32.x84:3.106.0.v20170608-0516
- org.eclipse.swt:org.eclipse.swt.win32.win32.x84_x64:3.106.0.v20170608-0516
- org.eclipse.swt:org.eclipse.swt.gtk.linux.x84:3.106.0.v20170608-0516
- org.eclipse.swt:org.eclipse.swt.gtk.linux.x84_x64:3.106.0.v20170608-0516
- more variants for Linux and MacOS

It does not matter against which SWT library you're compiling, but the user's 
of the library will require a 
different SWT library depending on their target platform. Therefore the library 
declares a dependency to 
org.eclipse.swt:org.eclipse.swt.${swt.platform}:3.106.0.v20170608-0516 and the 
property is set based on 
profiles in the project's parent.

Separate artifacts of this library do not make sense, it is always the same 
save the dependency to the SWT 
library.

Any solution without profiles? I don't see one and the property has to be kept 
in the customer POM also.

Regards,
Jörg


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

Re: Build vs Consumer POM study

[Jörg Schaible]

Am Mon, 12 Mar 2018 01:12:52 +0100 schrieb Hervé BOUTEMY:

[snip]

>> > Why is  required for consumers? I'm not aware how profiles
>> > of a dependency ever play(ed) a role in my "dependent" project?
>> I can remember we had a discussion about that..my first reaction would
>> be saying no profiles needed in a consumer pom...but I'm not 100%
>> sure...we need to think that more in detail with different scenarios..
> Robert has a strong opinion on this, for profiles activated by OS or JDK
> version, like flatten-maven-plugin

How would you solve this case then:

Somewhere in a parent pom:
== %< =
  
linux-amd64

  
linux
amd64
  


  org.eclipse.swt.gtk.linux.x86_64

  
  
windows-amd64

  
windows
amd64
  


  org.eclipse.swt.win32.win32.x86_64

  
  
== %< =

Somewhere in a child project X:

== %< =
  

  org.eclipse.swt
  ${swt.artifactId}
  3.106.0.v20170608-0516

  
== %< =

What would a consumer-pom.xml of X look like and how can a client of X 
still depend on the proper dependency for its target platform?

Cheers,
Jörg


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

Re: Maven 4.0.0

[Jörg Schaible]

Hi Romain,

Am Thu, 09 Nov 2017 09:32:12 +0100 schrieb Romain Manni-Bucau:

> FYI opened https://github.com/apache/maven/pull/136 for the MNG-6302
> (guess we can switch from thread to discuss it now?)

How is this issue related with my topic regarding improved Tycho support 
in Maven 4.0.0?

Regards,
Jörg


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

Re: Maven 4.0.0

[Jörg Schaible]

Hi,

one wish: Better integration with pom-less Tycho projects.

Currently it is not possible to run Maven and use standard Maven-based 
and pom-less Tycho-based projects in one reactor if the Tycho projects 
have dependencies on the Maven-based projects.

AFAICS the problem is that Polyglott is used to generate the temporary 
POMs out of the MANIFEST.MF on the fly, but the reactor-phase has already 
passed that calculates the build order.

It would be nice to adjust Maven Core in a way that allows such 
extensions contribute to the build order.

Cheers,
Jörg


Am Sat, 04 Nov 2017 12:20:18 + schrieb Stephen Connolly:

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



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

Re: Maven release plugin

[Jörg Schaible]

Petar Tahchiev wrote:

> Hey guys,
> 
> my pull-request worked fine to not show the prompt to specify a version.
> However, it fails to update snapshot dependency versions when you resolve
> the parent to a concrete version.
> Particularly in my case:
> 
> 
> [BOM]
>  /\
>  [PLATFORM]  [DEMO_STORE]
>-module1 - platform:module1
>-module2 - platform:module2
>  .
>- moduleN- platform:moduleN
> 
> The [BOM] defines in dependencyManagement section all the versions of the
> modules of the [PLATFORM]. Then the [DEMO_STORE] can reference them
> without specifying a version. During release what I do is I first release
> the
> [BOM], then release the [PLATFORM] and up to here I see no problems. But
> then I try to release the DEMO_STORE] and even though I specify on the
> command line the version of the parent [BOM]:
> 
> -Ddependency.com.nemesis:bom.release=1.5.2.RELEASE
> -Ddependency.com.nemesis:bom.development=1.5.3.BUILD-SNAPSHOT
> 
> 
> it still asks me for versions of dependencies which are specified in the
> released [BOM].

What you can do as workaround is to add an empty relativePath element to the 
[DEMO_STORE] as a temporary modification just for the release. Annoying, but 
that should limit the multi-project to the subtree.

> I tried patching the code and specifying a new version of
> the parent
> 
> project.getParentArtifact().setVersion("1.5.2.RELEASE")
> 
> just to see if it works, but the problem is that the dependencies in the
> project are already resolved: when I call project.getDependencies() I get
> the SNAPSHOT versions.
> 
> Is there any way to reload the project model after I specify a new
> parentVersion()? So that It understands the [BOM] is no longer a snapshot
> version.

Dependency resolution is too early for such modifications.

Cheers,
Jörg


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

Re: Is there a maven plugin for storing the dependency information in the jar?

[Jörg Schaible]

Owen O'Malley wrote:

> On Tue, Jun 20, 2017 at 11:36 AM, Jochen Wiedmann
> > wrote:
> 
>> On Tue, Jun 20, 2017 at 7:01 PM, Owen O'Malley 
>> wrote:
>>
>> >Is there already a plugin for storing the transitive dependency
>> > information in the jar's META-INF as part of the build? I'd like to
>> build a
>> > dynamic class loader that would be similar to shared libraries on
>> > Linux/Unix, but part of that is that I need the dependency information
>> > stored in the jar.
>>
>> I'd hope, that dependency:list could help you here. A little bit of
>> parsing might be required to read the output, but it worked for me in
>> the past.
>>
> 
> I'd seen dependency:list (and dependency:tree), but I need the information
> to automatically end up in the jar. Since the goal is to read it at
> process launch, having a binary format would be best to minimize the
> latency.

dependency:list has an outputFile configuration entry and if the goal is 
called in the generate ressources phase and the file is written to 
target/generated-ressources it will be picked up for the jar file.

Cheers,
Jörg


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

Re: [MNG-5567] Zip files are not included in classpaths at all

[Jörg Schaible]

Michael Osipov wrote:

> Folks,
> 
> what to do with this issue? There has been too much discussion about a
> simple and valid extension.
> 
> It is actually a no-brainer..ITs are pending...

I won't call it no-brainer if you scew up existing project setups. And I 
addressed the issue now twice here on the list.

Cheers,
Jörg


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

Re: Building a Java9 project just using JDK9

[Jörg Schaible]

Hi Enrico,

Enrico Olivelli wrote:

> Thank you all for your quick answers
> 
> @Robert
> I have checked out the code and took a deeper look:
> the implementation of MWAR-397 is complex and will take some time, on the
> mid term I agree that it will an awesome solution
> https://issues.apache.org/jira/browse/MWAR-397
> 
> @Jörg
> The option --permit-illegal-access will not work for me as it will hide
> most of the problems of Java9 fo

At least it writes still any violation to stderr. As said, that is also just 
a temporary solution.

> I would like to propose a simpler patch which prevents the
> maven-war-plugin from crashing at clinit
> https://github.com/apache/maven-plugins/pull/112
> 
> this will make it work just by disabling the cache
> I see it is a very temporary fix but lets everyone go on with Java9
> Webapps
> 
> If the idea is good a can file a JIRA, clean up the code respecting the
> conventions or the project and file a clean PR

In that case you might simply overload XStream's setupConverters method and 
register only the converters used for the scenario in the war-plugin. If the 
object graph does not contain a TreeSet, there's no need to initialize and 
register a converter for it.

> Another fallback would be to use the Kryo library, which let's you
> serialize non-serializable objects, but I have not tests

Cannot say anything about it.

Cheers,
Jörg


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

Re: Building a Java9 project just using JDK9

[Jörg Schaible]

Enrico Olivelli wrote:

> Il lun 10 apr 2017, 18:57 Karl Heinz Marbaise  ha
> scritto:
> 
>> Hi,
>>
>> On 10/04/17 17:37, Enrico Olivelli wrote:
>> > Hi,
>> > I would like be able to build an existing project developed for java8
>> > by simple running Maven on jdk9.
>> >
>> > Actually it is not possible, I am aware of that and I am currently
>> > following all the news about Maven and Java9
>>
>> What is not possible ? Do you have an error message / log file etc. ?
>>
> 
> Actually I am blocked on the TreeMap issue with xstream and
> maven-war-plugin.
> Is there any active work on that issue?
>  I see it is marked as an external dep problem but on xstream issue
>  tracker
> it seems that it is not a priority

You should be able to run it with MAVEN_OPTS="--permit-illegal-access" - at 
least until a solution is available.

Cheers,
Jörg


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

Re: Surefire and Java 9

[Jörg Schaible]

Hi Tibor,

Tibor Digana wrote:

> Hi Joerg,
> 
> We will continue on this issue after this release.
> Would you help us with your Java 9 knowhow?

actually, I am completely lost with Java 9 for now. I simply assumed that 
someone managed to run the unit tests by now that opens access to some class 
internals that are currently forbidden due to the new module system. Just to 
get an impression what stuff is actually affected.

> We have a ticket with Java9 issue in Jira.

Currently I am still doing research ...

Cheers,
Jörg


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

Surefire and Java 9

[Jörg Schaible]

Hi,

does anyone already have a setup to execute surefire with Java 9 where the 
tested code requires the opening of some modules? I already tried with 
different configuration stuff, but failed so far.

Cheers,
Jörg


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

Re: Maven Site / Report Plugins

[Jörg Schaible]

Hi,

Maxim Solodovnik wrote:

> then maybe copy/paste a little:
> 
> configure all necessary reports in parent pom (exclude github-report)
> Then add github-report to all child projects except one

or configure the github-report in the parent in a profile that is activated 
on existance of a "profiles/github" file. That is easier to maintain for 
multiple sub project requiring this report.

[snip]

Cheers,
Jörg


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

Extensions

[Jörg Schaible]

Hi,

Maven supports an own extension mechanism described in 
https://maven.apache.org/pom.html#Extensions. I was under the expresseion 
that it can be used to inject new components into the Plexus container that 
are available for any other plugin (as long as they set the extensions flag 
to true).

However, I failed to use this mechanism to declare new components to handle 
mar artifacts (Axis 2 modules). I added a jar file as extension containing a 
single file in META-INF/plexus/components.xml with the following content:

= %< =

  

  org.apache.maven.artifact.handler.ArtifactHandler
  mar
  
org.apache.maven.artifact.handler.DefaultArtifactHandler
  
mar
mar
jar
true
true
  


  org.codehaus.plexus.archiver.UnArchiver
  mar
  
org.codehaus.plexus.archiver.zip.ZipUnArchiver
  per-lookup

  

= %< =

Then I tried to use the UnArchiver component with the maven dependency 
plugin (goal: unpack-dependencies) to extract the contents of a dependency 
declared as:

= %< =
  
org.apache.axis2
ping
1.6.4
mar
compile
  
= %< =

However, the goal fails, it claims it does not know about a proper 
UnArchiver for artifacts of type 'mar'.

In contrast, if I declare the jar file with the plexus component descriptor 
as direct dependency of the dependency plugin, the descriptor is found and 
the mar file can be unpacked (independent of the setting for the extensions 
flag).

Why is the new component descriptor not considered if declared as extension? 
I wonder if the behavior is right or did I stumble over a subtile bug in 
Maven (3.3.9)?

Cheers,
Jörg


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

Re: MNG-5567: Zips on classpath

[Jörg Schaible]

Hi Michael,

Michael Osipov wrote:

> Am 2017-02-09 um 21:10 schrieb Benson Margulies:
>> -1 to zips on the classpath. We need to disentangle the java classpath
>> from the general concept of 'module X depends on module Y'. I created
>> quite a lot of code that uses zips as containers to pass files from
>> one place to another, and would be horribly broken if their transitive
>> dependencies started showing up.
> 
> This is because we finally need packaging zip. It would solve your
> problem.

Sorry, maybe I don't understand a concept here, but how does this solve the 
problem for existing zips (with classifiers)? IMHO their packaging type is 
also "zip" and if these zip files suddenly transport dependencies it will 
break existing projects.

Cheers,
Jörg


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

Re: MNG-5567: Zips on classpath

[Jörg Schaible]

Hi,

there's currently a discussion in JIRA regarding MNG-5576 (Zips on classpth) 
and Michael Osipov suggested to bring the discussion to the dev list. 
Actually this already happened once last August: 

Paul Benedict wrote:

> I would like to reopen MNG-5567 because I find the solution incomplete. As
> the ticket stands today, any "zip" listed as a dependency will get put on
> the classpath. The rationale behind that decision was:
> 
> (a) the classpath supports "zip" extensions
> (b) there is apparently no harm in automatically putting everything "zip"
> on the classpath
> (c) there is no apparent reason to opt-out
> 
> I have an issue with (b) and (c). Here's why:
> 
> First, it violates the principle that developers should control what goes
> on the classpath. I really can't believe Maven would wrestle this control
> away. The assumption that every "zip" is meant to be on the classpath is
> erroneous. This is not the case and Maven shouldn't automatically assume
> it. Even if Maven was to assume it, the lack of opt-in behavior gives no
> escape hatch.
> 
> Second, for projects that I personally deal with, these "zip" artifacts
> are nothing but shared front-end web resources. These are not meant to on
> the class path. The dependencies are there so other goals can unpack them
> during the build and place them in the context root.
> 
> Third, it's possible a "zip" non-classpath resource could conflict with a
> same named resource in the classpath. I haven't had to be concerned with
> this (yet), but I will be on the lookout if MNG-5567 doesn't change.

my concern is also (b), because it is today quite common to use the assembly 
plugin to create attached artficats with additional resources required later 
elsewhere (SQL scripts, WSDLs and their schema files, start scripts, ...). 
None of this stuff is meant to be on classpath.

On top, all these artifacts will suddenly inject transitive dependencies 
whereever they are referenced - just by using a new Maven version. We'll 
face bloated WARs and EARs with stuff not belonging there for *existing* 
projects. IMHO MNG-4467 has much more unwanted side-effects in the curent 
ecosystem compared to the support of one or two projects that deliver their 
Java archives as ZIP files.

Cheers,
Jörg



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

Re: Requesting a single Monorepo enhancement for Maven

[Jörg Schaible]

Hi Paul,

Paul Hammant wrote:

> OK, so I'm a documenter of Google's Monorepo (one bg ass trunk) and
> it's usage of shell scripts to subset the checkout for speedy development:
> 
>http://paulhammant.com/2014/01/06/googlers-subset-their-trunk/
>https://trunkbaseddevelopment.com/monorepos/
> 
> For Maven to be used with a scripted use of Subversion or Git's
> sparse-checkout (or Perforce's client spec), it'd been to be more like
> Bazel/Blaze or Buck, in that sub-modules are *not* forward declared, they
> are discovered/calculated/inferred somehow.
> 
> In pom.xml instead of -
> 
>   
> one
> two
>
> 
> We'd need -
> 
>   
> recursively
>
> 
> Or -
> 
>   
> .full-module-list.txt
> 
>
> 
> Thoughts?
> 
> Any questions?
> 
> - Paul H
> 
> PS - I'm a solid Maven user since 2003.

we did something like that just with bash scripts and it boils down to to a 
simple shell function. In the follwing example it creates module entries for 
all direct subdirectories containing a pom.xml file, but you might easily 
adjust this to some expression using globs, find or a list in a file.

 %< 

function createBuilder()
{
local artifactId
local path

artifactId=${1##*/}
cat > "$1"/pom.xml <
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd;>

4.0.0
builder
$artifactId
pom
x-SNAPSHOT
Builder $artifactId


EOF
while read path; do
if [ -f "$path" ]; then
continue
fi
path=${path##*/}
cat >> "$1"/pom.xml <$path
EOF
done < <(ls -d "$1"/*)
cat >> "$1"/pom.xml <

EOF
}

 %< 

Cheers,
Jörg



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

Re: Parent Version maybe not needed in child POM

[Jörg Schaible]

Tibor Digana wrote:

> Is it really necessary to specify version of parent artifact in ?
> 
> Suppose we have multimodule reactor project and maven-release-plugin would
> inline the version in the  section and remove it again in new
> development iteration. The plugin fails then if the parent version is not
> determined.
> 
> WDYT?
> 
> If I specify {project.version} in child POM dependencies I do it for the
> reason to not to know anything about inconsistent versions. The parent
> section with specific version breaks this idea because the parent runs
> child and thus child should know the caller.
> Maybe groupId+artifactId+relativePath in parent would be enough in such
> project.

The problem starts when you get the child POM from a repository. And *a* 
repository might already be the local one. I.e. your suggestion with the 
automated manipluation must happen already at installation/deployment time.

Cheers,
Jörg


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

Re: [DISCUSSION] finishing Aether import: help find a new name

[Jörg Schaible]

Uwe Barthel wrote:

> Hi,
> 
>> Eclipse owns the Aether name. We cannot use the name Aether.
> 
> And the Eclipse Foundation doesn't like to provide that name to the ASF
> (only the name without the eclipse namespace)?
> 
> Aethel means over the AIR.
> 
> WDYT about org.Apache.maven.air: _A_rtifact _I_inqui_R_e. Inquire is more
> general than resolve?
> 
> -- barthel

Prepend 'M' ... ;-)

Mare

M_aven
A_rtefact
RE_solver

- Jörg


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

Re: Maven Release Plugin And A BOM

[Jörg Schaible]

Hi Petar,

Petar Tahchiev wrote:

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

The point is, that Maven does not recreate the effective POM to build again 
the list of versions to resolve. It's simply a corner case. Some might argue 
it is undefined behavior, others might say it's a bug ;-)

Cheers,
Jörg


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

Re: Maven Release Plugin And A BOM

[Jörg Schaible]

Petar Tahchiev wrote:

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

You mean, you let the release plugin resolve the parent? We always manually 
"resolved" the parent first...

Cheers,
Jörg



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

Re: Fully qualified dependency names in war

[Jörg Schaible]

Hi Karl Heinz,

Karl Heinz Marbaise wrote:

> Hi,
> 
> I want to ask something related to your question:
> 
> On 4/10/16 2:12 PM, jieryn wrote:
>> Where should I look for providing an option to have the fully
>> qualified GAV name specified in built WAR files? Sometimes this
>> happens automatically when two short jar names would be added to
>> WEB-INF/lib, the second one will be added with the fully specified
>> GAV.
> 
> Do you have an example where this happens automatically ? That sounds
> like a bug or a non documented feature ;-) ..?

Feature. Used if two artifacts have same artifactId but different groupId. 
It is documented somewhere, but I don't remember where. Might be a feature 
of a shared component though.

Cheers,
Jörg


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

Re: [VOTE] Maven 3.3.9

[Jörg Schaible]

+1

Jason van Zyl wrote:

> Hi,
> 
> Time to release Maven 3.3.9!
> 
> Here is a link to the issues resolved:
> 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12333074
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1233/
> 
> The distributable binaries and sources for testing can be found here:
> 
https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/
> 
> Specifically the zip, tarball, and source archives can be found here:
> 
https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-bin.zip
> 
https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-bin.tar.gz
> 
https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-src.zip
> 
https://repository.apache.org/content/repositories/maven-1233/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-src.tar.gz
> 
> Source release checksum(s):
> apache-maven-3.3.9-src.zip sha1: 2b783992afcba54255f46508d582fe656e2c37dc
> 
> Staging site:
> http://people.apache.org/~jvanzyl/maven-3.3.9/
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Thanks,
> 
> Jason
> 
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
> 
> A party which is not afraid of letting culture,
> business, and welfare go to ruin completely can
> be omnipotent for a while.
> 
>   -- Jakob Burckhardt



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

Re: [VOTE] Release Apache Maven Shade Plugin version 2.4.2

[Jörg Schaible]

Hi Karl Heinz,

Karl Heinz Marbaise wrote:

> Hi Tibor,
> 
> On 10/20/15 11:12 PM, Tibor Digana wrote:
>> @Karl Because of maven-parent:27 this plugin is built with J2SE 6.0 = 50
>> (0x32 hex)
>> The previous version 2.4.1 was @ Java 5.
> 
> Unfortunately you are correct...(really good catch)...
> 
>> What is intended with this release?
> 
> It was not intended, cause no related issue is part of the release
> notes...

in our company we enforce now in the release profile always a special JDK 
version to avoid unintended JDK compatibility issues.

This might also be a solution for Maven plugins in general.

Cheers,
Jörg


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

Re: Full migration to Git

[Jörg Schaible]

Kristian Rosenvold wrote:

> This did not go well. I was able to get a full backup of asf svn up on
> my server, but unfortunately git-svn barfed on it. So I suppose some
> heavy filter-branching over the current git-svn clones is the only way
> to go,

Never tried myself, but reposurgeon is supposed to work also directly on svn 
dumps:

http://www.catb.org/esr/reposurgeon/reposurgeon.html

Cheers,
Jörg


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

HEADS-UP: maven.apache.org redirection oddity

[Jörg Schaible]

Hi,

there's a strange redirection rule working on then Maven website. When I am 
looking for a plugin's documentation, I enter often the direct link in the 
browser like:

 http://maven.apache.org/plugins/maven-jar-plugin/

Fine. That works. However, if I enter

 http://maven.apache.org/plugins/maven-jar-plugin

I am redirected to

 http://maven.apache.org/components/plugins/maven-jar-plugin/

At that location I get also the documentation, but all links to resources 
and in the breadcrumbs are broken.

Cheers,
Jörg


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

Re: [VOTE] Maven 3.3.5

[Jörg Schaible]

Hi Karl Heinz,

Karl Heinz Marbaise wrote:

 Hi,
 
  
 = % =
 $ MAVEN_OPTS=-Xmx4096m mvn validate
 
 Why are you setting to 4 GiB ?
 
 but for Maven 3.0.5 you only setting to 1.5 GiB ?

Because with M305 I *can* build the project with just 1.5 GB, but M33x 
fails with 3GB to calculate even the project order (well, I kill the process 
after several minutes of eating a lot of CPU cycles and the complete memory 
I've spent).

With 4GB I can at least run mvn validate using M335 (at least when I close 
Eclipse first) although it will take 3 times longer to finish the task (see 
reported times in this thread) and *a lot* more memory.

Cheers,
Jörg


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

Re: [VOTE] Maven 3.3.5

[Jörg Schaible]

Hi Igor,

Igor Fedorenko wrote:

 I am pretty sure somebody provided an example project that showed memory
 increase in Maven 3.2.x some time last year iirc.

That was me. I've provided everything to run mvn validate on the project 
tree. I have that archive still around.

 Could have been direct
 email, not 100% sure.

At least over a private channel, since the project is not public.

 From what I remember, the problem was triggered by
 specific way to reference parent pom, this is why only few projects are
 affected. Our performance regression test suite caught the problem too,
 but we never had time/resources to fix it.
 
 Again, going by memory, there are several problems, each of which
 increases memory footprint, so the solution likely requires multiple
 changes in different parts of the core. Deduplication of inherited model
 elements, things like dependency, is the likely best long term
 solution, but it is also the most involved and will likely require
 changes to modello and the way models and constructed and used.
 
 http://www.mail-archive.com/dev%40maven.apache.org/msg102715.html

Ah, yes, you've created MNG-5669 ...

Cheers,
Jörg



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

Re: [VOTE] Maven 3.3.5

[Jörg Schaible]

Hi Christian,

Kristian Rosenvold wrote:

 You still do not have any publicly available project to reproduce this ?

Unfortunately it is not public. But I have (still) an archive with a project 
tree containing anything required to run mvn validate (incl. the remote 
repos and the local repo).

 Every time you complain about this I have compared 3.0.5 and 3.3.3,
 and every time I get the same result; 3.3.3 might have about 10% more
 allocated objects overall when compared to 3.0.5. There is something
 about your project that is different from the ones I am testing, and
 I'd really need a test project to find out what.

We use a global POM for our development department to synchronize all 
important 3rd party dependencies and the versions of our own releases. The 
parent hierarchy for a normal project is between 2 and 4. However, due to 
different release cycles of the individual projects, the complete build 
references also different versions of those parents. And this seems to eat 
up all this memory (see MNG-5669 as result of Igor's original examination).

Cheers,
Jörg


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

Re: [VOTE] Maven 3.3.5

[Jörg Schaible]

Hi Karl Heinz,

Karl Heinz Marbaise wrote:

 Hi,
 
 On 7/24/15 9:35 AM, Jörg Schaible wrote:
 Hi Karl Heinz,

 Karl Heinz Marbaise wrote:

 Hi,

   
 = % =
 $ MAVEN_OPTS=-Xmx4096m mvn validate

 Why are you setting to 4 GiB ?

 but for Maven 3.0.5 you only setting to 1.5 GiB ?

 Because with M305 I *can* build the project with just 1.5 GB, but M33x
 fails with 3GB to calculate even the project order (well, I kill the
 process after several minutes of eating a lot of CPU cycles and the
 complete memory I've spent).

 With 4GB I can at least run mvn validate using M335 (at least when I
 close Eclipse first) although it will take 3 times longer to finish the
 task (see reported times in this thread) and *a lot* more memory.
 
 Are you running within Eclipse ?

No. Never.

Cheers,
Jörg


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

Re: [VOTE] Maven 3.3.5

[Jörg Schaible]

Hi folks,

M335 needs even more memory (see also 
http://thread.gmane.org/gmane.comp.jakarta.turbine.maven.devel/116287). 
Maven 3.3.x is for me now simply unusable at all:

= % =
$ MAVEN_OPTS=-Xmx4096m mvn validate
[INFO] Scanning for projects...
Downloading: 
http://localhost/~maven/repo-m2-snapshot/com/scalaris/buildsystem/maven2/master/x-SNAPSHOT/maven-metadata.xml
Downloaded: 
http://localhost/~maven/repo-m2-snapshot/com/scalaris/buildsystem/maven2/master/x-SNAPSHOT/maven-metadata.xml
 (813 B at 11.2 KB/sec)
Downloading: 
http://localhost/~maven/repo-m2-snapshot/ip/ip-master/5.0.x-SNAPSHOT/maven-metadata.xml
Downloaded: 
http://localhost/~maven/repo-m2-snapshot/ip/ip-master/5.0.x-SNAPSHOT/maven-metadata.xml
 (588 B at 57.4 KB/sec)
Downloading: 
http://localhost/~maven/repo-m2-snapshot/com/essencio/components/mobile/master/5.0.x-SNAPSHOT/maven-metadata.xml
Downloaded: 
http://localhost/~maven/repo-m2-snapshot/com/essencio/components/mobile/master/5.0.x-SNAPSHOT/maven-metadata.xml
 (613 B at 66.5 KB/sec)
Downloading: 
http://localhost/~maven/repo-m2-snapshot/com/scalaris/projects/cs/lc/master/3.0.x-SNAPSHOT/maven-metadata.xml
Java HotSpot(TM) 64-Bit Server VM warning: INFO: 
os::commit_memory(0x00073af8, 513802240, 0) failed; error='Cannot 
allocate memory' (errno=12)
#   
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 513802240 bytes for 
committing reserved memory.
# An error report file with more information is saved as:
# /home/jos/work/hs_err_pid21596.log
= % =

Back to M305 now, -Xmx1500m is enough ...

- Jörg



Jason van Zyl wrote:

 Hi,
 
 Time to release Maven 3.3.5!
 
 Here is a link to the issues resolved:
 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922version=12333058
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-1200/
 
 The distributable binaries and sources for testing can be found here:
 
https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/
 
 Specifically the zip, tarball, and source archives can be found here:
 
https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/apache-maven-3.3.5-bin.zip
 
https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/apache-maven-3.3.5-bin.tar.gz
 
https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/apache-maven-3.3.5-src.zip
 
https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/apache-maven-3.3.5-src.tar.gz
 
 Source release checksum(s):
 apache-maven-3.3.5-src.zip sha1: f2b28783fbf9a4fda47d2924a29aa99b9dc7b898
 
 Staging site:
 http://people.apache.org/~jvanzyl/maven-3.3.5/
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1
 
 Thanks,
 
 The Maven Team
 
 
 
 
 
 
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org



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

Re: [VOTE] Maven 3.3.5

[Jörg Schaible]

Hi Anton,

Anton Tanasenko wrote:

 Hi Jörg,
 
 The error message you posted says that java is unable to allocate 500mb of
 heap. The machine you were running it on didn't have that much available
 at the time.

If you think it is normal that I have to close Eclipse just to call mvn 
validate ... however, even if that command succeeds, we have:

== % ===
[INFO] Total time: 01:01 min
[INFO] Finished at: 2015-07-23T15:26:32+02:00
[INFO] Final Memory: 2056M/3641M
== % ===

compared to 

== % ===
[INFO] Total time: 17.512s
[INFO] Finished at: Thu Jul 23 15:46:39 CEST 2015
[INFO] Final Memory: 365M/1063M
== % ===

with M305 for the same project tree.

Cheers,
Jörg

 
 2015-07-23 15:47 GMT+03:00 Jörg Schaible joerg.schai...@swisspost.com:
 
 Hi folks,

 M335 needs even more memory (see also
 http://thread.gmane.org/gmane.comp.jakarta.turbine.maven.devel/116287).
 Maven 3.3.x is for me now simply unusable at all:

 = % =
 $ MAVEN_OPTS=-Xmx4096m mvn validate
 [INFO] Scanning for projects...
 Downloading:
 http://localhost/~maven/repo-m2-snapshot/com/scalaris/buildsystem/maven2/master/x-SNAPSHOT/maven-metadata.xml
 Downloaded:
 http://localhost/~maven/repo-m2-snapshot/com/scalaris/buildsystem/maven2/master/x-SNAPSHOT/maven-metadata.xml
 (813 B at 11.2 KB/sec)
 Downloading:
 http://localhost/~maven/repo-m2-snapshot/ip/ip-master/5.0.x-SNAPSHOT/maven-metadata.xml
 Downloaded:
 http://localhost/~maven/repo-m2-snapshot/ip/ip-master/5.0.x-SNAPSHOT/maven-metadata.xml
 (588 B at 57.4 KB/sec)
 Downloading:
 http://localhost/~maven/repo-m2-snapshot/com/essencio/components/mobile/master/5.0.x-SNAPSHOT/maven-metadata.xml
 Downloaded:
 http://localhost/~maven/repo-m2-snapshot/com/essencio/components/mobile/master/5.0.x-SNAPSHOT/maven-metadata.xml
 (613 B at 66.5 KB/sec)
 Downloading:
 http://localhost/~maven/repo-m2-snapshot/com/scalaris/projects/cs/lc/master/3.0.x-SNAPSHOT/maven-metadata.xml
 Java HotSpot(TM) 64-Bit Server VM warning: INFO:
 os::commit_memory(0x00073af8, 513802240, 0) failed; error='Cannot
 allocate memory' (errno=12)
 #
 # There is insufficient memory for the Java Runtime Environment to
 continue.
 # Native memory allocation (mmap) failed to map 513802240 bytes for
 committing reserved memory.
 # An error report file with more information is saved as:
 # /home/jos/work/hs_err_pid21596.log
 = % =

 Back to M305 now, -Xmx1500m is enough ...

 - Jörg



 Jason van Zyl wrote:

  Hi,
 
  Time to release Maven 3.3.5!
 
  Here is a link to the issues resolved:
 

 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922version=12333058
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-1200/
 
  The distributable binaries and sources for testing can be found here:
 

 
https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/
 
  Specifically the zip, tarball, and source archives can be found here:
 

 
https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/apache-maven-3.3.5-bin.zip
 

 
https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/apache-maven-3.3.5-bin.tar.gz
 

 
https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/apache-maven-3.3.5-src.zip
 

 
https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/apache-maven-3.3.5-src.tar.gz
 
  Source release checksum(s):
  apache-maven-3.3.5-src.zip sha1:
  f2b28783fbf9a4fda47d2924a29aa99b9dc7b898
 
  Staging site:
  http://people.apache.org/~jvanzyl/maven-3.3.5/
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  Thanks,
 
  The Maven Team
 
 
 
 
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org



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


 
 



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

Re: [VOTE] Maven 3.3.5

[Jörg Schaible]

Jörg Schaible wrote:

 Hi Anton,
 
 Anton Tanasenko wrote:
 
 Hi Jörg,
 
 The error message you posted says that java is unable to allocate 500mb
 of heap. The machine you were running it on didn't have that much
 available at the time.
 
 If you think it is normal that I have to close Eclipse just to call mvn
 validate ... however, even if that command succeeds, we have:
 
 == % ===
 [INFO] Total time: 01:01 min
 [INFO] Finished at: 2015-07-23T15:26:32+02:00
 [INFO] Final Memory: 2056M/3641M
 == % ===
 
 compared to
 
 == % ===
 [INFO] Total time: 17.512s
 [INFO] Finished at: Thu Jul 23 15:46:39 CEST 2015
 [INFO] Final Memory: 365M/1063M
 == % ===
 
 with M305 for the same project tree.


and M335 is slightly worse than M333:

== % ===
[INFO] Total time: 01:37 min
[INFO] Finished at: 2015-07-23T15:55:43+02:00
[INFO] Final Memory: 2050M/3480M
== % ===

Cheers,
Jörg

 
 Cheers,
 Jörg
 
 
 2015-07-23 15:47 GMT+03:00 Jörg Schaible joerg.schai...@swisspost.com:
 
 Hi folks,

 M335 needs even more memory (see also
 http://thread.gmane.org/gmane.comp.jakarta.turbine.maven.devel/116287).

[snip]



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

RE: Default Maven Compiler Version

[Jörg Schaible]

Hi Jason,

Jason Pyeron wrote:

 -Original Message-
 From: Manfred Moser [mailto:manf...@mosabuam.com]
 Sent: Thursday, June 18, 2015 12:21 AM
 To: dev@maven.apache.org
 Subject: Re: Default Maven Compiler Version
 
 Yes... a corporate or some other higher level pom is
 
 I think some detail was missed in the OP's question.
 
 It is not that he always wants version X. It is he wants the default to be
 the version in the path for each system.
 
 In other words: On system A it should be java version A on system B it
 should be java version B, etc.
 
 Maybe start with this idea:
 
 properties
   maven.compiler.source${java.version}/maven.compiler.source
   maven.compiler.target${java.version}/maven.compiler.target
 /properties
 
 Now I know that ${java.version} is likley to have some cruft in it, but
 someone better than I can come up with a way to strip out the 1.x from the
 java.version.

this can be achieved with automatically activated profiles for specific JDK 
versions and setting there the appropriate version as property value.

However, this makes repeatable builds even more brittle (now, you're 
depending on the current environment).

Cheers,
Jörg



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

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

[Jörg Schaible]

Hi Arnaud,

Arnaud Héritier wrote:

 On Mon, Apr 13, 2015 at 11:16 PM, Jörg Schaible joerg.schai...@gmx.de
 wrote:

[snip]

 IMHO, mvjars will create a bigger maintenance mess than the current
 solutions.

 
 I don't know. I think it really depends if your are provider or consumer
 of mvjars. If you are consumer you may imagine to not have to manually
 switch anymore between several implementations (using classifiers )
 and it gives you the ability to do the selection at runtime and not at
 build time. As producer I agree that it won't be easy if tools (Build,
 IDE) aren't providing a good/simple support. That's why Oracle (Brian) is
 trying to involve us.

Actually my biggest fear is for such a feature that some people will find 
*very* creative ways to use it. Therefore I hope that mvjars will be 
consequently restricted e.g. they should not be allowed to provide changes 
in the API for different versions. Better safe than sorry.

- Jörg


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

Re: [DISCUSSION] JEP 238: Multi-Version JAR Files

[Jörg Schaible]

Hi Arnaud,

Arnaud Héritier wrote:

 In short/middle term the lack of IDE integration isn't a real problem for
 now.
 Like Brian said, they know that users won't use such feature before
 several years.
 The runtime part providing the compatibility for the JRE should be
 backported to Java 8 but only Java 9 JDK will provide required tools to
 create such jars.
 The goal to involve build tools ASAP is to validate the technical
 feasibility to integrate such new feature before J9 is out (and not to
 wait for its delivery to do it - and complain when it will be too late)

You can already use several executions for the compiler plugin to create a 
jar file with classes targeting different JDKs. That's what XStream does for 
years already.

The challenge is that you have multiple class files with same name.
 
 What we need to do here is to imagine how it will be in 2/3? years when
 we'll start to have developers using a JDK9 who'll want to provide
 librairies compatible (and optimized) for previous JREs.
 
 For me (in my dreams) it should clearly be in only one module and thus
 probably with additional sources directories. The compiler plugin should
 hide (in one or several steps) the compilation of sources and the jar
 packaging should discover if it has to create a mvjar or not

You have different use cases here. One time you have one Java source that 
will behave different depending against which runtime libs you have compiled 
(e.g. a different overloaded method is used). In another scenario your Java 
code actually differs.

So, for Maven there might be several src folders ... or you have annotations 
at types, methods and/or fields indicating the target runtime.

However, the result should be a jar file that allows a client to write code 
that is indifferent of the multiple versions of a class. Wait ... maybe the 
client will have to create a mvjar himself, because the different versions 
also result in different versions of his own code (think about JDBC api) 
...?

IMHO, mvjars will create a bigger maintenance mess than the current 
solutions.

- Jörg


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

Re: 3.3.1: Memory Usage

[Jörg Schaible]

Hi,

I already reported this for 3.2.3 
(http://thread.gmane.org/gmane.comp.jakarta.turbine.maven.devel/113979), 
provided Igor with an archive containing anything to run validate (I have it 
still) and this resulted in https://jira.codehaus.org/browse/MNG-5669. 
However, the issue in still unresolved and the situation did not improve.

More answers inline.

Karl Heinz Marbaise wrote:

 Hi,
 
 have you pinned all plugins correctly and get no difference in the
 plugins version during the different executions?

Pinned.

 Have you defined any kind of profiles etc. or memory configurations?
 Which JDK are you using? OS is of course interesting as well...

Gentoo Linux-3.18.7

Java(TM) SE Runtime Environment (build 1.7.0_76-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.76-b04, mixed mode)

 Are you using the exact same machine?

Yes.

 Or running on a CI system which
 uses different nodes to execute?

No.

 Which filesystem is under the hood on
 this machine?

ext4 on SSD.


 On 3/21/15 12:00 PM, Robert Scholte wrote:
 It also seems to be a time-issue.
 
 looks odd...
 
 
 I would like to see these numbers over, let's say, 10 runs. (OS and JDK
 the same of course)
 
 +1 for this...

The results are rather constant. In contrast to the results in my original 
mail I have now 522 projects in the build. Still no problem for M305 with 
1.5GB, but M331 runs OOM with 3GB now.

10 times with M305 (-Xmx1536m):
= % ===
[INFO] Total time: 21.360s
[INFO] Final Memory: 366M/1103M
[INFO] Total time: 17.612s
[INFO] Final Memory: 367M/1122M
[INFO] Total time: 20.013s
[INFO] Final Memory: 368M/1101M
[INFO] Total time: 19.400s
[INFO] Final Memory: 370M/1105M
[INFO] Total time: 16.759s
[INFO] Final Memory: 369M/1152M
[INFO] Total time: 17.997s
[INFO] Final Memory: 369M/1148M
[INFO] Total time: 18.993s
[INFO] Final Memory: 367M/1100M
[INFO] Total time: 19.385s
[INFO] Final Memory: 369M/1103M
[INFO] Total time: 17.020s
[INFO] Final Memory: 366M/1044M
[INFO] Total time: 18.984s
[INFO] Final Memory: 369M/1103M
= % ===

10 times with M331 (-Xmx4g):
= % ===
[INFO] Total time: 53.801 s
[INFO] Finished at: 2015-03-23T13:22:39+01:00
[INFO] Final Memory: 1937M/3591M
[INFO] Total time: 50.849 s
[INFO] Finished at: 2015-03-23T13:23:35+01:00
[INFO] Final Memory: 1940M/3641M
[INFO] Total time: 51.883 s
[INFO] Finished at: 2015-03-23T13:24:32+01:00
[INFO] Final Memory: 1946M/3571M
[INFO] Total time: 48.187 s
[INFO] Finished at: 2015-03-23T13:25:26+01:00
[INFO] Final Memory: 1935M/3641M
[INFO] Total time: 53.555 s
[INFO] Finished at: 2015-03-23T13:26:24+01:00
[INFO] Final Memory: 1937M/3543M
[INFO] Total time: 51.795 s
[INFO] Finished at: 2015-03-23T13:27:21+01:00
[INFO] Final Memory: 1949M/3569M
[INFO] Total time: 54.271 s
[INFO] Finished at: 2015-03-23T13:28:21+01:00
[INFO] Final Memory: 1936M/3501M
[INFO] Total time: 47.280 s
[INFO] Finished at: 2015-03-23T13:29:13+01:00
[INFO] Final Memory: 1947M/3601M
[INFO] Total time: 47.663 s
[INFO] Finished at: 2015-03-23T13:30:06+01:00
[INFO] Final Memory: 1945M/3527M
[INFO] Total time: 55.549 s
[INFO] Finished at: 2015-03-23T13:31:07+01:00
[INFO] Final Memory: 1935M/3502M
= % ===

 One thing worth investigating is if the buildplan related instances can
 be cleaned up.

The build only contains what's currently required. However, in case of HEAD 
it is nearly anything.


 thanks,
 Robert

 Op Wed, 18 Mar 2015 11:19:33 +0100 schreef Jörg Schaible
 joerg.schai...@swisspost.com:

 Hi,

 it seems to get my standard complaint about every new Maven version, but
 we're currently stuck to Maven 3.0.5. One reason is the vast memory
 usage of
 any later version.
 
 Ok you have one reason to stuck with Maven 3.0.5...what are the other
 reasons ?

In case of a branch we have a lot less projects in the build, but in that 
case M3 fails for us to build them in proper order and we even have to use  
M221. Different story though (MNG-5207). 

We're also stuck with the site plugin version 3.0-beta-3 (resp. 2.2 for 
M221) because of MSITE-604 and MSITE-664.

[snip]

Cheers,
Jörg


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

3.3.1: Memory Usage

[Jörg Schaible]

Hi,

it seems to get my standard complaint about every new Maven version, but 
we're currently stuck to Maven 3.0.5. One reason is the vast memory usage of 
any later version.

We have currently ~450 projects in the reactor, now compare the results of a 
simple validate:

Maven 3.0.5:
 % ==

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time: 19.312s
[INFO] Finished at: Wed Mar 18 10:50:10 CET 2015
[INFO] Final Memory: 323M/1106M
[INFO] 

 % ==

Maven 3.3.1 (and 3.2.5):
 % ==

[INFO] BUILD SUCCESS
[INFO] 

[INFO] Total time: 54.811 s
[INFO] Finished at: 2015-03-18T10:44:44+01:00
[INFO] Final Memory: 1806M/2731M

 % ==

Understandably the situation worsens if you actually try to build.

Cheers,
Jörg


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

Re: Maven 3.2.6

[Jörg Schaible]

Hi Andreas,

Andreas Gudian wrote:

 I can handle that, but not before the weekend.
 
 Jason, does that conflict with your schedule for the release?
 
 Perhaps we just say that we drop the support for old Windows versions with
 3.3.0 and do the actual work that removes the support from the bat files
 in the next minor release?
 
 I would imagine that no one out there cares for Windows 98/ME anyway ;-).

Rename them also to *.cmd, they're no DOS batches anyway.

Cheers,
Jörg


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

Re: Preview release: Plexus Archiver multithreaded Zip edition

[Jörg Schaible]

Kristian Rosenvold wrote:

[snip]

 Inside commons-compress this target is always a
 tempfile. Inside plexus-archiver OffloadingOutputStream (a
 commons-compress ScatterOutputStream) is used. This writes to some
 pretty huge memory buffers, but when a certain treshold is reached it
 offloads to tempfile while retaining what was initially written to
 memory. I'll be putting this offloading stream class in commons-io
 fairly soon.

commons-io has DeferredFileOutputStream with such a functionality, did you 
miss it?

Cheers,
Jörg


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

Re: OT: Xpp3 parser

[Jörg Schaible]

Hi Jason,

Jason van Zyl wrote:

 We do, it's been in plexus-utils for years in the
 org.codehaus.plexus.util.xml.pull package.

Hmm. You took a private copy of the API (normally in xmlpull:xmlpull) and of 
xpp3:xpp3. However, since the Plexus parser no longer implements the 
official API (org.xmlpull.v1.XmlPullParser) it cannot be used as replacement 
for the official Xpp3 (or like KXML2).

I always assumed Maven is based on the original Xpp3 artifact. Nevermind.

Cheers,
Jörg

 
 On Jan 1, 2015, at 7:37 PM, Jörg Schaible joerg.schai...@gmx.de wrote:
 
 Hi guys,
 
 can someone tell me who nowadays maintains the Xpp3 parser?
 http://www.extreme.indiana.edu/xgws/xsoap/xpp/mxp1/index.html is online,
 but Bugzilla or CVS is no longer available.
 
 Cheers,
 Jörg



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

OT: Xpp3 parser

[Jörg Schaible]

Hi guys,

can someone tell me who nowadays maintains the Xpp3 parser? 
http://www.extreme.indiana.edu/xgws/xsoap/xpp/mxp1/index.html is online, but 
Bugzilla or CVS is no longer available.

Cheers,
Jörg


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

Re: Need Jira account

[Jörg Schaible]

Benson Margulies wrote:

 Where did you see that?

Long-standing annoying story:
http://jira.codehaus.org/browse/HAUS-2323

 For codehaus, you interact with xircles
 (that's where most of the Maven jira project are).

- Jörg


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

Re: maven-eclipe-plugin build failing due to Could not generate DH keypair

[Jörg Schaible]

Benson Margulies wrote:

 Well, the only users would be either people using old versions of Eclipse,
 or very stubborn people trying to use it in the teeth of m2e.

Or users that explicitly remove m2e from their Eclipse installation because 
even without it current Eclipse is quite unstable and extremely resource 
hungry.

- Jörg


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

Re: Ticket Transition Workflow: Abandoned issues

[Jörg Schaible]

Stephen Connolly wrote:

 I think we can add whatever states we want.
 
 These are not Backlog though
 
 They are perhaps Stale or Inactive/Unconfirmed
 
 Just need a label that communicates the ticket as closed due to no
 response and no clear report

Incomplete ;-)

 
 On Wednesday, November 26, 2014, Chris Graham chrisgw...@gmail.com
 wrote:
 
 RTC uses Backlog. Does Jira have something similar?

 Sent from my iPhone

 On 27/11/2014, at 8:13 AM, David Jencks david_jen...@yahoo.com.INVALID
 wrote:

  Retired rather than Archived?
 
  This cleanup seems like a really good idea :-)
 
  david jencks
 
  On Nov 26, 2014, at 12:41 PM, Paul Benedict pbened...@apache.org
 javascript:; wrote:
 
  My 2-cents on the word Archived is that it's a synonym for
  Backup/Storage, which I don't think is what this process is about.
 
 
  Cheers,
  Paul
 
  On Wed, Nov 26, 2014 at 1:57 PM, Michael Osipov micha...@apache.org
 javascript:; wrote:
 
  Am 2014-11-26 um 16:16 schrieb Paul Benedict:
 
  This email is related to thread Abandoned bug analysis [1].
 
  We have done the Great Ticket Cleanup of 2014 twice this year. It
  has really been productive for anyone who triages outstanding bugs
  and enhancements. We've been adding a note in the ticket, as a
  courtesy
 to the
  participants, and closing them as Won't Fix.
 
  This is certainly one valid way of accomplishing the goal. However,
  I
 do
  believe we should enhance our workflow by adding an Abandoned (my
 fav)
  or
  Archived resolution. Why? Because Won't Fix is typically is used
 to
  close out a bug that will never be fixed (i.e., too many people rely
 on
  the
  bad behavior) or the enhancement is deemed worthless or incorrect.
  But more
  importantly, it's not possible to do a JIRA search and distinguish
 between
  these two conditions unless a new resolution is introduced.
 
 
  We need two new things:
 
  1. Status: Awaiting Feedback (not just labels).
  2. Resolution: Archived
 
  Michael
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 javascript:;
  For additional commands, e-mail: dev-h...@maven.apache.org
 javascript:;
 
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:;
  For additional commands, e-mail: dev-h...@maven.apache.org
 javascript:;
 

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


 



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

Regression: Reactor memory consumption/leak

[Jörg Schaible]

Hi folks,

we have a single build with currently ~400 projects (incl. builders i.e. 
POMs having modules only). We are already used to increase the provided 
memory in MAVEN_OPTS, but lately we have troubles to build at all because of 
OOMEs (heap). Look at following numbers building with the different Maven 
versions (latest Oracle JDK 7 on 64-bit Linux):

== % ===
$ MAVEN_OPTS=-Xmx640m mvn-3.0.5 validate
...
[INFO] -
[INFO] BUILD SUCCESS
[INFO] -
[INFO] Total time: 25.392s
[INFO] Finished at: Thu Oct 16 10:02:56 CEST 2014
[INFO] Final Memory: 276M/511M
[INFO] -
== % ===
3.0.5 fails with 512 only.


== % ===
MAVEN_OPTS=-Xmx1100m mvn-3.1.1 validate
...
[INFO] -
[INFO] BUILD SUCCESS
[INFO] -
[INFO] Total time: 37.004s
[INFO] Finished at: Thu Oct 16 10:13:36 CEST 2014
[INFO] Final Memory: 431M/978M
[INFO] -
== % ===
3.1.1 fails with 1024m only.


== % ===
MAVEN_OPTS=-Xmx2500m mvn-3.2.3 validate
...
[INFO] -
[INFO] BUILD SUCCESS
[INFO] -
[INFO] Total time: 55.465 s
[INFO] Finished at: 2014-10-16T10:27:42+02:00
[INFO] Final Memory: 1488M/M
[INFO] -
== % ===
3.2.3 fails with 2400m only.


The required memory increases dramatically from Maven version to version 
just to calculate the build order list (the OOME occurs before this list is 
printed).

- Jörg


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

Re: Regression: Reactor memory consumption/leak

[Jörg Schaible]

Hi Jason,

Jason van Zyl wrote:

 Igor and I have been moving a vast project with hundreds of modules (200
 to 400 to 500) from 3.1.0 through 3.2.4-SNAPSHOT and don't observe this
 drastic change. We would definitely notice.
 
 Are all your plugin versions locked down in that they don't vary  even
 though the version of Maven does? 

Except eclipse and help plugin - yes.

 Also are you running reporting in here?

In validate? No. However, it does not reach this point at all:

== % ==
$ mvn-3.2.3 validate
[INFO] Scanning for projects...
Downloading: 
http://es3.elsag.de/~maven/repo-m2-snapshot/com/scalaris/buildsystem/maven2/master/x-SNAPSHOT/maven-metadata.xml
Downloaded: 
http://es3.elsag.de/~maven/repo-m2-snapshot/com/scalaris/buildsystem/maven2/master/x-SNAPSHOT/maven-metadata.xml
 (813 B at 10.7 KB/sec)
Downloading: 
http://es3.elsag.de/~maven/repo-m2-snapshot/ip/ip-master/5.0.x-SNAPSHOT/maven-metadata.xml
Downloading: 
http://es3.elsag.de/~maven/repo-m2-snapshot/ip/ip-master/4.4.x-SNAPSHOT/maven-metadata.xml
Downloading: 
http://es3.elsag.de/~maven/repo-m2-snapshot/com/essencio/components/mobile/master/5.0.x-SNAPSHOT/maven-metadata.xml
[ERROR] GC overhead limit exceeded - [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/OutOfMemoryError
== % ===

- Jörg


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

Re: Regression: Reactor memory consumption/leak

[Jörg Schaible]

Hi Igor,

Igor Fedorenko wrote:

 Can you provide an example project we can use to reproduce the problem
 locally? You may be able to strip your source tree from everything bun
 pom.xml files, for example.

Interesting idea. I'll try if this works out.

- Jörg


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

Re: Regression: Reactor memory consumption/leak

[Jörg Schaible]

Hi Igor,

Igor Fedorenko wrote:

 Can you provide an example project we can use to reproduce the problem
 locally? You may be able to strip your source tree from everything bun
 pom.xml files, for example.

OK, this works out. I have now such a transportable setup. It's zipped about 
1.1MB with an empty local repository or 38MB with a filled one. I can run

 MAVEN_OPTS=-Xmx3000m mvn validate -s settings.xml

successfully and will fail with OOME calling

 MAVEN_OPTS=-Xmx2000m mvn validate -s settings.xml

using M323/Java7 on Linux x64. The project tree contains the pom.xml and 
anything that triggers profiles automatically. Any non-public artifact is in 
a remote repo (included in the 1.1MB), so you should be able to reproduce 
this. Which do you want and what's the most useful place to put this?

Cheers,
Jörg


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

Re: Regression: Reactor memory consumption/leak

[Jörg Schaible]

Hi Igor,

Igor Fedorenko wrote:

 You can zip and email it to me directly or share it on github, dropbox
 or google drive and send me the link. I am flexible :-)

I've sent the small one directly ...

Cheers,
Jörg


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

Re: Next Maven prerequisite for Maven Plugins

[Jörg Schaible]

Robert Scholte wrote:

 Hi,
 
 Right now we change the Maven prerequisite to 2.2.1 and I noticed some new
 issues which already want to move it forward to 3.0.4. I wonder why to
 move to this version.
 
 Most (API-)changes have been introduced with the 3.0 alpha and beta
 releases. I don't think that the other 3.0.x releases provide that much
 more changes.
 So I would say that changing the required Maven version would be 3.0.
 *If* we want to force users not to use 3.0.4 due to the CVE-2013-0253, we
 should say that 3.0.5 is the next required version of Maven.
 And I could go one step further: if we want to get rid of the
 compatibility overhead for Aether (Sonatype versus Eclipse) we should
 change it to 3.1.0
 
 So I'd prefer to move forward to 3.0, maybe even to 3.1.0, but not to
 3.0.4 unless there are better reasons then I mentioned above.
 
 Any other opinions?

That's the point we always feared, because as long MNG-5207 is not solved, 
Maven 2.2.1 is the last version that produces for us reliable results at 
all.

- Jörg


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

Re: Hanging builder staging site

[Jörg Schaible]

Hi Karl-Heinz,

Karl Heinz Marbaise wrote:

 Hi,
 
 does someone know where to look cause currently the site staging job
 seemed to blocked and waiting for 11 hours
 
 
 http://ci.apache.org/builders/maven-site-staging

Maybe it waits for manual input on stdin (e.g. new password)?

- Jörg


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

Re: POM 5.0 and Maven.next idea - re: repository's

[Jörg Schaible]

Hi Mark,

Mark Derricutt wrote:

 In last weeks dev hangout I raised the idea of removing repository
 elements due to some issues with them regarding mirrors etc which was
 somewhat negatively received, however I've been thinking about this a
 bit and came up with an interesting idea earlier in the night whilst at
 a gig.
 
 One of the problems I'm often seeing is that:
 
 1) a project uploads their artefact to a repository ( mostly maven
 central )
 2) 90% of their dependencies are available from the repository in
 question
 3) 1 critical dependency is not - which ultimately means you can't
 build..if you have a mirror setup
 
 (usually because you've not noticed a repository declaration which you
 need to configure in your nexus/arifactory/archiva etc. )
 
 The idea I had is three fold:
 
 1) Fallback on original repository when a mirror doesn't resolve
 
 When maven is checking for a repository for an artefact, and using a
 mirror - if that artefact can't be found, maven should retry using the
 original repository directly with builds warnings.


Very bad idea. Especially if the original repo is not/no longer reachable 
and you have to wait for a timeout. And you can no longer control with an 
Archive Manager what actually is used from where.


 2) Deploy transitive runtime dependencies along with your release
 
 We currently have the distributionManagement section of a pom
 declaring the deploy repository. If we added a new `deploy-dependencies`
 goal to some plugin and updated maven-release-plugin with a this in its
 default deployment goals, I think some magical things could happen:
 
- Find the _runtime_ dependency tree of your project
- Check which artefacts don't exist on the deployment repo
- Deploy those artefacts out to the repository - essentially an
 implicit mirroring your dependencies.
 
 At the same time, modify the POM reader to add the repository defined in
 `distributionManagement` as a `repository` for discovering
 dependencies.
 
 Any thoughts on this? Since it's now 12:32am, _hopefully_ I'll be awake
 in time to join the discussion tomorrow to raise this idea.


And suddenly we have all kind of stuff in public repos that are not allowed 
to be distributed.

IMHO, the best option *is* actually to remove the repository elements. 

- Jörg



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

Re: Thoughts on MNG-3522

[Jörg Schaible]

Hi Igor,

Igor Fedorenko wrote:

 More I think about it, less I like the idea of explicit order values. I
 think this will be rather inconvenient to setup and error prone to
 maintain.
 
 Initial setup will require some tooling to see executions in a
 particular case with their default ordering values. Not the end of the
 world, but somebody will have to implement the tooling and the users
 will know how to find it.
 
 More problematic will be ongoing changes to the project itself
 and its parents. When I need to add/remove executions in a parent, I
 will have to review all projects that inherit from it to ensure order is
 still correct. I work on a monster codebase with 600+ modules now, I
 just don't see how this is workable.
 
 If executions are enabled through a profile, especially rarely activated
 profile, configuring expected order becomes really cumbersome.
 Think of -Prelease profile, that adds gpg mojo to package phase...
 good luck troubleshooting why signed jars do not match their gpg
 signatures during the release.
 
 I think we need to find a way to make before/after hints work. I don't
 have a proposal yet, but I wonder, is this not the same problem as
 ordering modules in the reactor? When there are no dependencies, modules
 are built in their specified order, but the order changes when there are
 dependencies.

please have a look at the latest comments on MNG-3522, because adding 
executions in a profile causes some edge cases, which should be defined in 
advance.

Regards,
Jörg


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

Re: Not a local repository. It is a local repository cache. (was: Fwd: Why Is Maven Ignoring My Local Repo?)

[Jörg Schaible]

ROBERT PATRICK wrote:

 I don't understand the issue.  I regularly use artifacts in my build that
 are only present in my local repository.  Yes, Maven checks my remote
 repository for these artifacts but it doesn't ignore them if they are not
 in the remote repo.  It also works when building offline without access to
 my remote repository.  Is it treated as a cache, maybe so but it's not
 clear to me that renaming the tag won't serve to add more confusion to a
 long-standing behavior...
 
 Clearly, removing the ability to install artifacts locally would be a very
 bad idea since it would make it more difficult for casual users to use
 Maven for casual builds (e.g., I regularly use it to build sample projects
 for customers that I never intend to do anything else with once I send it
 to the customer).

A remote repository is specified with an URL. Nobody prevents you from using 
a file URL i.e. having a real local repository on your disk.

- Jörg


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

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jörg Schaible]

Hi Mark,

Mark Derricutt wrote:

 On 7 Apr 2014, at 12:32, Benson Margulies wrote:
 
 We then have other logical classpaths. . Something like javadoc should
 be able to define another named classpath structure; combining the
 dependencies of the plugin's implementation with dynamic code
 (doclets, whatever) seems like a category confusion to me.
 
 If we change/break this - can we PLEASE make the compilation path IGNORE
 transitive dependencies of 'compile' dependencies - if I -need- it to
 compile, -I- should depend on it up front.

I made the same request more than 7 years ago 
(https://jira.codehaus.org/browse/MNG-2589). However, you can already force 
such a mode with some own effort using a common POM with a depMgmt section 
declaring anything with runtime scope. Unfortunately such a mode reveals 
some nasty effects of the Java model and we finally gave in. See my comment 
in MNG-2589 of last year.

- Jörg


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

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jörg Schaible]

Hi Jason,

Jason van Zyl wrote:

 Hi,
 
 I started making of list of things I'd like to remove in Maven 4.0.0, but
 I would like to start getting some agreement on what we can yank and this
 is the first concrete request. I would like to remove the ability for
 plugins to magically inject dependencies. Plugins can either declare their
 dependencies or instruct users to add dependencies to the plugins in their
 POMs. This weird logic for plugins to add dependencies dynamically is the
 cause of some extremely convoluted logic in the resolution code and I want
 to remove it.
 
 The original issue is here: http://jira.codehaus.org/browse/MNG-4363
 
 I encountered this when trying to hoist all the resolution logic into once
 place so that from our Aether provider resolution as it is done in the
 core can be done everywhere. Right now we have plugins like the assembly
 plugin, WAR plugin, dependency plugin that all do their own weird,
 inconsistent thing and when I tried to put it all in one place so that it
 can be analyzed, optimized and then executed this issue cropped up. We
 never should have allowed this in the first place but carried it over from
 2.x for compatibilities sake. This might affect the code coverage tools
 but we can find a cleaner way. This logic is totally bizarro and needs to
 go.
 
 If everyone agrees we can start systematically documenting what has been
 removed, as we have lost track of this accurately in the past. I'd like to
 make a 4.x branch in 4 weeks or so and this will be one of the first
 things I'd like to cut. It will be one of those radical simplifications
 that will start allowing people to get a better understanding of the core
 as I can put the resolution logic in one place as it is currently in many.

Do you only mean injecting new dependencies into the classpath or injecting 
new ones into the reactor that will have to be considered for dependency 
resolution? MNG-4363 talks of the former, your proposal seems to include the 
latter.

How do you then intent to resolve dynamically dependencies with different 
classifiers?

The dependency plugin does this explicitly for its sources and javadoc goals 
(resolving artifacts with corresponding classifier). The site plugin does it 
implicitly with an artifact having a site classifier. And we have 
developed an own plugin doing the same to aggregate documentation from the 
dependencies.

It does not make sense for these cases to declare those artifacts with a 
(different) classifier. What about this scenario?

- Jörg


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

Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies

[Jörg Schaible]

Jason van Zyl wrote:

 On Apr 7, 2014, at 3:19 AM, Jörg Schaible joerg.schai...@swisspost.com
 wrote:
 
 Hi Jason,
 
 Jason van Zyl wrote:
 
 
 If everyone agrees we can start systematically documenting what has been
 removed, as we have lost track of this accurately in the past. I'd like
 to make a 4.x branch in 4 weeks or so and this will be one of the first
 things I'd like to cut. It will be one of those radical simplifications
 that will start allowing people to get a better understanding of the
 core as I can put the resolution logic in one place as it is currently
 in many.
 
 Do you only mean injecting new dependencies into the classpath or
 injecting new ones into the reactor that will have to be considered for
 dependency resolution? MNG-4363 talks of the former, your proposal seems
 to include the latter.
 
 
 My proposal is strictly to prohibit a plugin from modifying a project's
 classpath implicitly. That this become fully explicit such that I can
 remove some of the convoluted logic in the core to account for this.
 
 How do you then intent to resolve dynamically dependencies with different
 classifiers?
 
 The dependency plugin does this explicitly for its sources and javadoc
 goals (resolving artifacts with corresponding classifier). The site
 plugin does it implicitly with an artifact having a site classifier.
 And we have developed an own plugin doing the same to aggregate
 documentation from the dependencies.
 
 It does not make sense for these cases to declare those artifacts with a
 (different) classifier. What about this scenario?
 
 
 I'm not exactly sure what your question is. Do you mean how would you
 accomplish these types of tasks without using the resolver directly and do
 this declaratively?

No, the plugin should use the resolver and a user should not have to declare 
such artifacts as dependencies ... just as it is now.

Cheers,
Jörg


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

Re: [VOTE] Maven 2.x is end of life

[Jörg Schaible]

Stephen Connolly wrote:

 We have not made a release of Maven 2.x since 2.2.1 which was August 2009.
 
 During that period no release manager has stepped up to cut a release.
 
 I would argue that we should just therefore just declare Maven 2.x as end
 of life.

-1

This vote is real-life comedy as long as there is no newer version that 
succeeds with its core competence to build multi-projects in correct order 
and therefore will not produce artifacts with bogus SNAPSHOTs.

Embarassed,
Jörg

 
 This vote is therefore to resolve this issue.
 
 The vote will be decided on the basis of committer votes cast. If the
 majority of votes from committers (which includes PMC members) are in
 favour then we will declare 2.x end of life.
 
 If you are a committer and voting -1, then we will assume that you are
 willing to step up and act as a release manager to get a 2.2.2 release out
 (which would hopefully include being able to not barf on
 maven-metadata.xml that uses the snapshotVersions schema generated by
 Maven 3.x but the release manager gets to decide what it is they want to
 release)
 
 The decision on this is actually quite simple as if there is nobody
 committer to act as a release manager for the 2.x line, then it is end of
 life.
 
 +1: Maven 2.x is end of life, I am not willing to act as release manager
 for this line of releases
 0: I have no opinion
 -1: Maven 2.x is not end of life, I am willing to act as release manager
 for this line of releases
 
 The vote will be open for 72h and may be closed earlier in the unlikely
 event that all Maven committers have cast a vote before the 72h are up.
 
 -Stephen



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

Re: [VOTE] Maven 2.x is end of life

[Jörg Schaible]

Daniel Kulp wrote:

 
 On Feb 13, 2014, at 11:18 AM, Stephen Connolly
 stephen.alan.conno...@gmail.com wrote:
 
 I suggest you convince at least one of these people:
 https://people.apache.org/committers-by-project.html#maven that they
 should act as release manager.
 
 EOL just means we will not be making new releases, and it will be moved
 to the archive section of the downloads.
 
 Well, one more thing:  if it’s officially EOL, there is a much higher
 chance that plugins would be marked as using 3.x as a minimum and will no
 longer work with 2.1.1.   API’s and such that the plugins use will likely
 get updated to 3.x level.  Etc….

Right. The question is already if 2.2.1 runs on Java 8 or if we have a 
compatible release plugin that allows us to switch from subversion to git. 
With EOL of M221 those situations will grow rapidly.

 Anyway, I’m +1 to dropping 2.x support.

I'd switch immediately to a working 3.x version.

 You will still be able to download it. You will still be able to get the
 source code. We just will be recognising the fact that there is nobody
 who wants to cut a release from the 2.x codebase.

See above. 2.2.1 can become a dead end faster than wanted.
 
 Hopefully focusing on the 3.x codebase will allow us to iron out the bugs
 you feel are present in 3.x and thus preventing you from migrating...

What else can we do apart from digging into Maven/Aether code ourselves? 
Providing an example project and an IT did not help to make any progress.

- Jörg



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

Re: [VOTE] Maven 2.x is end of life

[Jörg Schaible]

Hi,

Stephen Connolly wrote:

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

 On 13 February 2014 17:15, Baptiste Mathus m...@batmat.net wrote:
 
 Hi Jörg,
  multi-projects in correct order and therefore will not produce
  artifacts
 with bogus SNAPSHOTs

 Maybe you could (re)point out the corresponding JIRAs?

 Because as a maven user, I wonder what triggers these issues for you. We
 have tens of multi-projects with interdependencies being currently
 developed, and I'd be interested to hear about the (problematic) use case
 we don't encounter.


The easiest way to detect if you're affected is by removing any SNAPSHOT 
from your repositories and run a build. If the build stops because SNAPSHOTs 
cannot be found that are part of your build, the problem is obvious.

- Jörg


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

Re: 3.2.0 Bug Scrub

[Jörg Schaible]

Hi Stephen,

Stephen Connolly wrote:

 I have added a wiki page summary of this discussion:
 
 https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.2.0+Bug+Scrub

I miss MNG-5207 bitterly on the radar. M3 is not able to calculate a proper 
build sequence and uses either a stale SNAPSHOT or the build breaks 
completely.

- Jörg


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

Re: 3.2.0 Bug Scrub

[Jörg Schaible]

Stephen Connolly wrote:

 Added... now how come it wasn't on the issue tracker list

Thanks!

- Jörg


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

Re: JAVA_HOME in release plugin

[Jörg Schaible]

Hi Bernd,

Bernd wrote:

 Hello,
 
 I am not sure where to get the codehaus.org JIRA account. Do I have to
 contact somebody at Apache or Codehaus?

xircles.codehaus.org (you need a full account, an account to manage the 
mailing lists only is not enough for JIRA).

- Jörg

http://jira.codehaus.org/browse/HAUS-2323


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

Re: Programmatically adding dependencies to a MavenProject

[Jörg Schaible]

Hi Benoit,

Benoit Billington wrote:

 @Manfred We cannot extract the jar into target/classes because the compile
 phase will not pick anything from target/classes but use that as output
 only. (I didn't check that but It makes sense :) )

Try to extract the jar and generated sources add that directory with the 
build-helper as additional source or resource to fool the compiler.

 @Jorg I cannot let the user set the dependency jar in the pom.
 1° the extracted path is different for every aar dependency
 2° android-maven-plugin should do it for the user as he only need to
 declare the aar in the pom
 3° the aar cannot be provided as it needs to be packaged into the apk

OK.

Cheers,
Jörg


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

Re: Programmatically adding dependencies to a MavenProject

[Jörg Schaible]

Benoit Billington wrote:

 I'm facing this problem too.
 
 Android has created a new format for its libraries called Android Archive
 (.aar)
 
 This format described here:
 http://tools.android.com/tech-docs/new-build-system/aar-format contains a
 /classes.jar
 
 How would I be able to add that classes.jar into my classpath before the
 compile phase as theses classes will be needed by my own classes.
 
 Using Android-Maven-Plugin we extract the .aar into target/unpack/...
 So I was thinking to add the classes.jar as a system scoped dependency
 
 Note:
 my pom contains the following dependency:
 dependency
 groupIdcom.example/groupId
 artifactIdmy-android-lib/artifactId
 version1.0.0/version
 typeaar/type
 /dependency
 
 I cannot add a jar dependency of the same artifactid  groupid because the
 aar is not grouped with a jar but contains it. so you will always find
 .aar only in Maven Central.
 dependency
 groupIdcom.example/groupId
 artifactIdmy-android-lib/artifactId
 version1.0.0/version
 typejar/type
 /dependency

Use a classifier ... e.g. classes.

- Jörg


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

Re: Programmatically adding dependencies to a MavenProject

[Jörg Schaible]

Manfred Moser wrote:

 Benoit Billington wrote:

 I'm facing this problem too.

 Android has created a new format for its libraries called Android
 Archive
 (.aar)

 This format described here:
 http://tools.android.com/tech-docs/new-build-system/aar-format contains
 a
 /classes.jar

 How would I be able to add that classes.jar into my classpath before the
 compile phase as theses classes will be needed by my own classes.

 Using Android-Maven-Plugin we extract the .aar into target/unpack/...
 So I was thinking to add the classes.jar as a system scoped dependency

 Note:
 my pom contains the following dependency:
 dependency
 groupIdcom.example/groupId
 artifactIdmy-android-lib/artifactId
 version1.0.0/version
 typeaar/type
 /dependency

 I cannot add a jar dependency of the same artifactid  groupid because
 the
 aar is not grouped with a jar but contains it. so you will always find
 .aar only in Maven Central.
 dependency
 groupIdcom.example/groupId
 artifactIdmy-android-lib/artifactId
 version1.0.0/version
 typejar/type
 /dependency

 Use a classifier ... e.g. classes.
 
 You are misunderstanding Joerg.

No. You have

=== % ===
dependency
 groupIdcom.example/groupId
 artifactIdmy-android-lib/artifactId
 version1.0.0/version
 typeaar/type
 scopeprovided/scope !-- do you need it on classpath ?? --
/dependency
dependency
 groupIdcom.example/groupId
 artifactIdmy-android-lib/artifactId
 version1.0.0/version
 typejar/type
 scopesystem/scope
 classifierclasses/classifier
 systemPath${basedir}/target/extracted/classes.jar/systemPath
/dependency
=== % ===

and configure the dependency plugin to extract the aar to target/extracted.

Have you tried that?

- Jörg


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

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

[Jörg Schaible]

Hi Jason,

Jason van Zyl wrote:

 When a release fails like this it is annoying to have to rev back the
 version of the POM. I'm not sure who flipped the versions in the POM and
 while it's a little more visible to see what you're moving toward I prefer
 the pattern of:
 
 3.1-SNAPSHOT -- 3.1.1 -- 3.1-SNAPSHOT -- 3.1.2 -- 3.1-SNAPSHOT
 
 I know this may not be obvious to the casual observer as they may think
 3.1 is next, but I'm personally fine with that.

That's quite funny, because we did this years ago when we started using M2 
and then we were told here in the list it is an anti-pattern, because 3.1-
SNAPSHOT is always minor for the dependency resolution than any 3.1.x 
release.

- Jörg


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

Re: maven 3.x and parent pom dependencies

[Jörg Schaible]

John Dix wrote:

 Hello,
 
 I am wanting to determine how maven determines where parent poms are if
 the relativePath tag is not in the parent section of a pom. Can
 someone please point me to where in the source code I should set a
 breakpoint and start look for this?

A missing relativePath element and the following expression are equally 
handled:

 relativePath../relativePath

- Jörg


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

Re: Adding support for new dependency mediation strategy

[Jörg Schaible]

Hi Stephen,

Stephen Connolly wrote:

 On 26 August 2013 08:27, Jörg Schaible joerg.schai...@scalaris.com
 wrote:
 
 Hi Stephen,

 Stephen Connolly wrote:

 [snip]

  It's better than that... I am not sure if I said it earlier or not, so
  I will try to say it now.
 
  When we get the next format, there are probably actually three files we
  want to deploy:
 
  foo-1.0.pom (the legacy 4.0.0 model)
  foo-1.0-build.pom (the new 5.0.0+ model)
  foo-1.0-deps.pom (the new 5.0.0+ model)
 
  Now foo-1.0.pom should be a resolved pom with only the bare minimum
  required elements, e.g. dependencies and hopefully nothing else... may
  need dependencyManagement, but I think we can collapse that down. No
  parent element.

 OK, this works for releases, but what about SNAPSHOTs? For SNAPSHOTs is
 is quite normal that your parent is also a SNAPSHOT and you would produce
 all kind of problems if you try to resolve/collapse SNAPSHOT parents for
 SNAPSHOT artifacts that are installed or deployed.

 
 Why?
 
 Or perhaps you are confusing what I mean?
 
 Basically the foo-1.0.pom that gets deployed/installed is the result of
 help:effective-pom with some bits removed, such as properties, build,
 reporting, profiles etc

I guess, you have your point by using different Maven versions. If someone 
uses a new POM model for his projects, it means that he will also use the 
new Maven. Any backward compatible POM seems in this case used only for 
projects using the older Maven and those will normally not rely on a 
SNAPSHOT.

 When building from a checkout, the reactor will have everything... and if
 you are depending on a deployed/installed -SNAPSHOT then the behaviour
 will remain the same.
 
 And since this would be for a new Maven, we need only concern ourselves
 that the contract of the new Maven's classpath and property behaviour is
 correct... thus we don't have to preserve the current crazyiness when you
 have a dependency that has transitive dependencies where parts of the GAV
 are linked by properties.

I hope, you're only referring to the usage of properties for the direct 
project version and the parent. In dependencyManagement (and 
pluginManagement) I really want to use distinct property constants ... it is 
so much more convenient and less error-prone.
 
 In short, by separating the build time pom from the deployed pom, we can
 maintain a defined reproducible behaviour[1] *and* migrate the schema
 
 [1]: That does not mean that Maven 4.0 will allow you to reproduce all of
 the classpath hacks that you can with Maven 2/3... some of those hacks are
 stupid (even if people insist on using them)... but it should mean that
 whatever classpath constructs you can do in Maven 4.0 get mapped correctly
 on a best effort basis to the legacy clients

- Jörg



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

Re: Adding support for new dependency mediation strategy

[Jörg Schaible]

Hi Stephen,

Stephen Connolly wrote:

 On 27 August 2013 09:46, Stephen Connolly
 stephen.alan.conno...@gmail.comwrote:
 
 On 27 August 2013 09:00, Jörg Schaible
 joerg.schai...@scalaris.comwrote:

  And since this would be for a new Maven, we need only concern
  ourselves that the contract of the new Maven's classpath and property
  behaviour is correct... thus we don't have to preserve the current
  crazyiness when
 you
  have a dependency that has transitive dependencies where parts of the
 GAV
  are linked by properties.

 I hope, you're only referring to the usage of properties for the direct
 project version and the parent. In dependencyManagement (and
 pluginManagement) I really want to use distinct property constants ...
 it is
 so much more convenient and less error-prone.


 I am saying that the properties being in the deployed *these are the
 runtime dependencies* pom causes issues...

 So that when deploying the foo-1.0-build.pom we would put in the EL
 expressions... but when deploying the foo-1.0-deps.pom we would fully
 resolve them to the property values at build time. (might have an
 exception for the system scope's path... if we keep system scope) because
 that frees the consumers from having to interpolate the properties and
 build the full model.

 In other words, we should make the -deps.pom easy to consume. The ${} EL
 expressions are exactly what you want in the human authored files... just
 not in the machine generated ones

OK. This means all the stuff we have currently in the shared parent 
(depMgmt/pluginMgmt and properties) will stay in the *-build.pom and work in 
this regard like before.
 
 By way of an example... your source code may have a pom file like:
 
 project
   modelVersion4.0.0/modelVersion
   parent
 groupIdlocaldomain.example/groupId
 artifactIdparent/artifactId
 version1.0-SNAPSHOT/version
   /parent
   artifactIdchild/artifactId
   properties
 junit.version4.0/junit.version
   /properties
   dependencies
 dependency
   groupIdjunit/groupId
   artifactIdjunit/artifactId
   version${junit.version}/version
 /dependency
   /dependencies
 /project
 
 When that gets deployed *by mvn4*, we could be deploying:
 
 * child-1.0-SNAPSHOT.pom
 
 project
   modelVersion4.0.0/modelVersion
   groupIdlocaldomain.example/groupId
   artifactIdchild/artifactId
   version1.0-SNAPSHOT/version
   dependencies
 dependency
   groupIdjunit/groupId
   artifactIdjunit/artifactId
   version4.0/version
 /dependency
   /dependencies
 /project
 
 * child-1.0-SNAPSHOT-deps.pom
 
 {
   modelVersion:5.0.0,
   id:localdomain.example:child:1.0-SNAPSHOT,
   dependencies:[
 junit:junit:4.0
   ]
 }
 
 * No child-1.0-SNAPSHOT-build.pom as the packaging is not `pom`
 
 Thus legacy consumers have a pom that they can parse that conforms to the
 legacy classpath but provides faster resolution, modern consumers can just
 look up the -deps.pom directly and parse that (note that I gave a JSON
 example both to be controvertial *and* to remind people that we can pursue
 other pom formats when we go to the next model version.

:)

Actually I'd like to see a simplified format (at least usage of attributes 
e.g. for GAV in XML).

 Now maybe there are issues with fully collapsing a modelVersion 4.0.0 pom
 when building with mvn4... so perhaps mvn4 would need to just deploy a
 modelVersion 4.0.0 pom as is, unmodified... that's fine IMHO... but with a
 modelVersion 5.0.0 pom in whatever format we pick for that, my opinion is
 that we should deploy the legacy pom fully resolved.

In consequence this will also implicitly drop (transitive) dependency 
manipulations with profiles.

However, all makes sense now to me - thanks for explaining.

- Jörg



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

Re: Adding support for new dependency mediation strategy

[Jörg Schaible]

Hi Stephen,

Stephen Connolly wrote:

[snip]

 It's better than that... I am not sure if I said it earlier or not, so I
 will try to say it now.
 
 When we get the next format, there are probably actually three files we
 want to deploy:
 
 foo-1.0.pom (the legacy 4.0.0 model)
 foo-1.0-build.pom (the new 5.0.0+ model)
 foo-1.0-deps.pom (the new 5.0.0+ model)
 
 Now foo-1.0.pom should be a resolved pom with only the bare minimum
 required elements, e.g. dependencies and hopefully nothing else... may
 need dependencyManagement, but I think we can collapse that down. No
 parent element.

OK, this works for releases, but what about SNAPSHOTs? For SNAPSHOTs is is 
quite normal that your parent is also a SNAPSHOT and you would produce all 
kind of problems if you try to resolve/collapse SNAPSHOT parents for 
SNAPSHOT artifacts that are installed or deployed.

[snip]

- Jörg


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

Re: Adding support for new dependency mediation strategy

[Jörg Schaible]

Hi Phillip,

Phillip Hellewell wrote:

 Hi all,
 
 I'd like to take a stab at adding support for Maven to be able to mediate
 dependency conflicts using highest version strategy rather than nearest
 definition.
 
 I'll be happy if anyone can point me in the right direction on which
 source
 files I'll need to modify, and any other guidance.  Also, how long do you
 expect such a task would take for a competent developer?
 
 Finally, I'm curious to know what are the chances of a patch being
 accepted
 when I'm done?  I'll of course do it in such a way that the default
 remains nearest definition, and this new strategy has to be enabled with
 a setting in settings.xml or something.

Can you also tell, why you really want to do this? If you really want 
predictability, then use a shared parent, declare all involved 
dependencies there in a dependencyManagement section and declare your direct 
dependencies without any version. This way you can specify any version 
explicitly.

- Jörg


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

Re: [VOTE] Release Apache Maven Model Converter version 2.3

[Jörg Schaible]

Hi Oliver,

Olivier Lamy wrote:

 On 15 August 2013 08:53, sebb seb...@gmail.com wrote:
 On 14 August 2013 21:21, Dennis Lundberg denn...@apache.org wrote:
 On Wed, Aug 14, 2013 at 10:47 AM, sebb seb...@gmail.com wrote:

 On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote:
  On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote:
  On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote:
 
 
  I have now read the threads that are referring to, and have not
  found a single link to any ASF rule stating that we need to
  include these things in a VOTE thread.
 
  So how do you propose that reviewers check the provenance of the
  files in the source release?
 
  Are you looking for files that are in a distribution that didn't
  come
 from source control? Everything else as far as provenance goes is
 covered. Errant content is a potential problem, but everything in a
 distribution should come from source control which no one has access to
 until they have a signed CLA on file.
 
  Yes. That is where the whole saga started.
 
  Proving provenance is why the SCM coordinates are needed for the
  vote.
 
  The SCM details may also be useful to discover files accidentally
  omitted from the source archive.
 
  You want to compare the contents of the *-source-release.zip with
  something from SCM, to make nothing bad has crept into the source
  bundle. So you need to know where in SCM you can find it. Have I
  understood you correctly?

 It's vital to be able to link the files in the source release
 archive(s) to their origin in SCM.

 The provenance of any source files the ASF releases must be clearly
 traceable.


 This information is clearly traceable and available to anyone who wants
 to review a release made by the Maven project. Our process uses the
 Release Plugin, which will put the POM from the SCM tag in the staging
 directory along with the source-release.zip. In that POM wou will find
 the URL to the original sources in SCM.


 As has already been pointed out, SVN tags are not immutable, so the
 tag name alone is not sufficient.
 
 I think Stephen perfectly sum up the situation.
 If you're not happy follow that.
 
 But please STOP the troll!

The Maven PMC has made clear, that it knows about the problems and want to 
ignore it. However, please understand that Sebb is playing devil's advocate 
here, because the same release process is used for other Apache projects 
where the PMCs will *not* ignore this flaws. Sebb is more or less pestering 
you, because he is tired of having the same discussions in projects where he 
*is* PMC and is therefore responsible for the release. So, it is a bit short 
sighted to declare him as troll, simply because you (the Maven PMC) decided 
to ignore the problem.

- Jörg


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

Re: Maven 3.1.0-beta-1

[Jörg Schaible]

Hi Jason,

Jason van Zyl wrote:

 Doesn't see to be a whole lot of activity around the 3.1.0-alpha-1 so I
 plan to cut the 3.1.0-beta-1 this weekend if there are no objections.

Apart from the reported bogus build with snapshots (MNG-5207) it seems M31 
has a major problem with PermGen space leakage.

We have currently a build that contains 337 projects. With M221 I can build 
all of it in one run in ~11 minutes.

With M305 the build runs faster, but I have to continue it two times with -
rf option, because it runs out of PermGen space.

With M31a the leakage is really worse. The build stops because of PermGen 
space 4 times, where I have to continue manually again.

All plugins are locked down, so it has to be related with Maven core. 
MAVEN_OPTS is -Xmx1g -XX:MaxPermSize=192m and I am running mvn clean 
install [-rf name].

Thanks,
Jörg


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

Re: Maven 3.1.0-beta-1

[Jörg Schaible]

Hi Jason,

did you had a chance to take a second look, following my instructions in my 
first reply?

Thanks,
Jörg

Jason van Zyl wrote:

 I unpacked your example and ran your preparation script and it fails in
 2.2.1 as well:
 
 https://gist.github.com/jvanzyl/5824206
 
 What's the overall usecase? You have a build with snapshots and you find
 you need to go back to a release so you lock down to a previous release
 and want to use that?
 
 If you want to iteratively work on it together put it in a github repo.
 
 On Jun 20, 2013, at 2:45 AM, Jörg Schaible joerg.schai...@scalaris.com
 wrote:
 
 Hi Jason,
 
 Jason van Zyl wrote:
 
 Doesn't see to be a whole lot of activity around the 3.1.0-alpha-1 so I
 plan to cut the 3.1.0-beta-1 this weekend if there are no objections.
 
 Since all versions of M30x fail in their core competence to make reliable
 builds because it uses stale snapshots, it would be fine to have at least
 a properly working M31x. What I am talking about? See MNG-5207! Reported
 months ago, a proper IT test bit rots in JIRA and if you search through
 the archives of this list for the issue, then you'll notice that it has
 been reported more than once, with promises to look into it. And yes, I
 have verified that M31a still fails.
 
 - Jörg
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 Three people can keep a secret provided two of them are dead.
 
  -- Benjamin Franklin



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

Re: Maven 3.1.0-beta-1

[Jörg Schaible]

Hi Jason,

first, thanks that you actually take your time to look into it!

Jason van Zyl wrote:

 I unpacked your example and ran your preparation script and it fails in
 2.2.1 as well:
 
 https://gist.github.com/jvanzyl/5824206

The submodules are independent projects, you have to run clean install. 
See the following session (I have modified the POMs of the children by 
adding a relativePath/ element, the original example is now ~2 years 
old):

https://gist.github.com/joehni/6aa8516bd5408144ec53

Note, that after a successful run with M221, the build with M3x will no 
longer fail, but pack stale snapshots. To raise an error, you have to clean 
the repo from snapshots in repohome/bugs/maven.

 What's the overall usecase? You have a build with snapshots and you find
 you need to go back to a release so you lock down to a previous release
 and want to use that?

The final distribution of our product or projects typically consists of 
hundreds of artifacts, where most of them have individual release cycles. In 
the HEAD revision those are linked in a nested directory structure using 
builder POMs i.e. POMs that have only modules declared, but get never 
released themselves (like the POM in the root of the example). The versions 
of the individual artifact are managed in a shared parent POM. In HEAD those 
are typically all snapshot versions.

This changes after a major release of the overall product, then all those 
versions become final, the shared parent is released first followed by all 
other artifacts in dependency order using this released parent. This works 
all fine.

Now we get into maintenance mode of that major release. Due to the 
independence of the artifacts we have to branch only the affected projects 
in case of bugs. Say we have JAR artifacts JAR-A to JAR-Z and we develop bug 
fixes for JAR-C and JAR-S. This means we branch the shared parent, set JAR-C 
and JAR-S to snapshot and also the artifacts that will assemble those to two 
jars, say WAR-X and DIST-ZIP. Then we create a builder for the maintenance 
branch that contains those jars, the war and the distribution zip as module. 
Building this we should get a war that contains JAR-C and JAR-S as snapshot 
and all the others as release and the distribution contains the affected 
WAR-X as snapshot and all other stuff as released version - the perfect 
situation to test the fix.

Unfortunately M3 fails here, because it is under some circumstance not able 
to calculate the proper build order (maybe it does no longer take attached 
snapshot artifacts into account ?!?) and will either pack a stale snapshot 
from the local repository or fail, because the snapshot is built at a later 
time.

 If you want to iteratively work on it together put it in a github repo.

If you bear with me, may day-to-day work is with svn only and my learning 
curve with git/github is still steep, e.g. I did not know about gists, so I 
already learned something new.

Cheers and thanks for your time,
Jörg



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

Re: Maven 3.1.0-beta-1

[Jörg Schaible]

Hi Jason,

Jason van Zyl wrote:

 Doesn't see to be a whole lot of activity around the 3.1.0-alpha-1 so I
 plan to cut the 3.1.0-beta-1 this weekend if there are no objections.

Since all versions of M30x fail in their core competence to make reliable 
builds because it uses stale snapshots, it would be fine to have at least a 
properly working M31x. What I am talking about? See MNG-5207! Reported 
months ago, a proper IT test bit rots in JIRA and if you search through the 
archives of this list for the issue, then you'll notice that it has been 
reported more than once, with promises to look into it. And yes, I have 
verified that M31a still fails.

- Jörg


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

Re: Maven 3.1.0-alpha-1 release notes

[Jörg Schaible]

Michael-O wrote:

 Am 2013-06-07 21:59, schrieb Jason van Zyl:
 Go for it.

 On Jun 7, 2013, at 3:47 PM, Michael-O 1983-01...@gmx.net wrote:

 Am 2013-06-07 20:18, schrieb Jason van Zyl:
 Looks like the Mardown processing isn't working correctly. The page
 definitely has a title.


 On Jun 7, 2013, at 1:59 PM, Michael-O 1983-01...@gmx.net
 http://gmx.net wrote:

 Am 2013-06-06 19:20, schrieb Jason van Zyl:
 I've pushed in the initial cut at the release notes if anyone wants
 to take a look:

 http://svn.apache.org/r1490364

 Jason,

 both pages [1] and [2] are missing a title in the apt files so the
 /html/head/title remains empty ('Maven -' actually). This should be
 fixed too.

 [1] http://maven.apache.org/maven-jsr330.html
 [2] http://maven.apache.org/maven-logging.html


 Should be file a JIRA ticket?
 
 Already a known issue for a year:
 http://jira.codehaus.org/browse/DOXIA-472

At least Benjamin's workaround works for now, so you can add a title.

- Jörg


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

Re: [VOTE] Apache 3.1.0-alpha-1

[Jörg Schaible]

Arnaud Héritier wrote:

 On Wed, May 29, 2013 at 7:39 AM, Hervé BOUTEMY
 herve.bout...@free.frwrote:
 
 good idea: can you open a Jira issue?

 
 Done :  https://jira.codehaus.org/browse/MNG-5482
 Another probably more stupid idea : Wasn't it possible to use the shade
 plugin or something like this to provide a version of aether under the old
 groupId to not have such requirement in plugins upgrades ? Something that
 we'll have been able to remove in a next major release (4)

Weird idea: A ClassLoader that exchanges the package name automatically, 
along with a fat deprecation warning?

- Jörg


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

Re: [VOTE] Should we respin CANCELLED releases with the same version number?

[Jörg Schaible]

-1 (nb)

Stephen Connolly wrote:

 We have been using a policy of only making releases without skipping
 version numbers, e.g.
 
 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, etc
 
 Whereby if there is something wrong with the artifacts staged for release,
 we drop the staging repo, delete the tag, roll back the version, and run
 again.
 
 This vote is to change the policy to:
 
 drop the staging repo, document the release as not released, and run with
 the next version.
 
 Under this new proposal, if the staged artifacts for 3.1.0 fail to meet
 the release criteria, then the artifacts would be dropped from the staging
 repository and never see the light of day. The tag would remain in SCM,
 and we would document (somewhere) that the release was cancelled. The
 respin would have version number 3.1.1 and there would never be a 3.1.0.
 
 This change could mean that the first actual release of 3.1.x might end up
 being 3.1.67 (though I personally view that as unlikely, and in the
 context of 3.1.x I think we are very nearly there)
 
 Please Note:
 http://maven.apache.org/developers/release/maven-project-release-procedure.html#Check_the_vote_resultsdoes
 not actually specify what it means by the process will need to be
 restarted so this vote will effect a change either outcome
 
 +1: Never respin with the same version number, always increment the
 version for a respin
 0: Don't care
 -1: Always respin with the same version number until that version number
 gets released
 
 This vote will be open for 72 hours. A Majority of PMC votes greater that
 3 will be deemed as decisive in either direction (i.e. if the sum is  -3
 or
 +3 then there is a documented result)
 
 For any releases in progress at this point in time, it is up to the
 release manager to decide what to do if they need to do a respin.
 
 -Stephen



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

Re: Desupport Maven 1

[Jörg Schaible]

Olivier Lamy wrote:

 2013/4/19 Brett Porter br...@porterclan.net:

[snip]

 - we're used 'retired' instead of 'archived' in the past. Though I'm not
 sure if we need to do that for SVN, particularly since it breaks tags. We
 could just put a big warning in the directory?
 agree.

... or simple move the trunks alone into branch:

[..]/maven/maven-1/core/trunk to [..]/maven/maven-1/core/branches/1.x

That way svn structure reflects the maintenance state without breaking the 
released versions in tags.

- Jörg


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

Re: [VOTE] Apache 3.1.0-alpha-1

[Jörg Schaible]

Hi Andrei,

Andrei Pozolotin wrote:

 *Wayne*
 
 1) in this case I choose madness :-)
 
 2) here is my request:
 please provide an option to modello or whoever is enforcing strict
 xml model in maven
 to relax the rules, so people can use maven they way it fits them,
 while enforcing the rules by default.

Then why don't you use custom properties that follow simple naming 
conventions? Just run in your mojo through the list of (resolved) 
dependencies and look if an appropriate custom property has been defined:

 dependencies
   ...
   dependency
  groupIdcom.example/groupId
  artifactIdbundle/artifactId
  version1.0.1/version
   /dependency
   dependency
  groupIdcom.example/groupId
  artifactIdbundle/artifactId
  version1.0.1/version
  classifierfeatures/classifier
  typexml/type
   /dependency
   ...
 /dependencies
 ...
 properties
   ...
   
karaf.com.example.bundle.osgiStartLevel99/karaf.com.example.bundle.osgiStartLevel
   
karaf.com.example.bundle.features.bootInstalltrue/karaf.com.example.bundle.features.bootInstall
   ...
 /properties

Obvious naming convention: karaf.groupId.artifactId[.classifier].variable

- Jörg


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

Re: Heads up: org.apache.maven.shared:maven-shared-incremental:jar:1.1

[Jörg Schaible]

Anders Hammar wrote:

 It should be in the same staged repo as the compiler plugin. See that VOTE
 thread.

:-/

Just at the time I wanted to report a regression for the compiler plugin 
3.0! I'll try to test 3.1 ...

- Jörg


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

Heads up: org.apache.maven.shared:maven-shared-incremental:jar:1.1

[Jörg Schaible]

Hi,

this artifact is missing in central:
org.apache.maven.shared:maven-shared-incremental:jar:1.1

http://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-shared-
incremental/

therefore the build of the compiler plugin fails.

Regards,
Jörg


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

Re: Pain with MNG-5181 (_maven.repositories)

[Jörg Schaible]

Andreas Gudian wrote:

  Am Freitag, 1. Februar 2013 schrieb Jason van Zyl :
 

 On Jan 31, 2013, at 7:13 PM, Arnaud Héritier
 aherit...@gmail.comjavascript:; wrote:

  Hi Olivier,
 
   Thx a lot for the fix. It will help a lot the community.
   But from my point of view it's perhaps not yet enough.
   We should :
   1/ change the default behavior to deactivate this control which is
  difficult to understand

 I disagree. We may want to change it slightly but it's only a problem for
 people who flip between Maven a repository manager and without but it's
 to ensure the identity of a component. I haven't seen a huge number of
 complaints. I do not want to turn this off. Improve it, sure, but turning
 it off by default I believe is not the right thing to do.


 How about turning it into a warning by default and only fail if you enable
 some meaningful option (or implicitly in some plugins such as the release
 plugin).
 
 But I must admit that I don't really have a use case in mind where failing
 is crucial.

We have a private plugin from an internal repository which has a goal that 
is executed during the build and a goal to generate a report. Unfortunately 
the jar of the plugin can no longer be resolved when it should generate the 
report. As it turns out, the site plugin is too old (3.0-beta-3). However, 
any newer version has a bug (MSITE-604) and site:deploy fails i.e. we cannot 
release with it. Catch-22.

- Jörg


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

Re: Wagons and thread safety....

[Jörg Schaible]

Stuart McCulloch wrote:

 On 10 Jan 2013, at 13:19, Kristian Rosenvold wrote:

[snip]

 In one way kind of neat; since the statement has both
 @plexus.requirement and final it's fairly obvious who sets it;
 although the semantics are definitely not java101 ;) Do you know if
 this works with old plexus too ? (2.2.1)
 
 It should also work with old Plexus, as that also uses setAccessible to
 break encapsulation - I seem to remember seeing some Plexus requirements
 that were already marked final

Requires at least Java 5 runtime i.e. fine with M221.

Cheers,
Jörg


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

Re: OutputStream that seamlessly switches to disk file?

[Jörg Schaible]

Kristian Rosenvold wrote:

 Anyone know a buffer (OututStream) that will stay in-memory until it
 reaches a given size then rolls over to a tempfile?
 
 I need one for my tan...?
 
 Kristian

http://commons.apache.org/io/apidocs/org/apache/commons/io/output/DeferredFileOutputStream.html


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

Re: [VOTE] Maven 3.1.0

[Jörg Schaible]

Hi Arnaud and Dan,

Arnaud Héritier wrote:

 On Thu, Nov 29, 2012 at 3:41 PM, Daniel Kulp dk...@apache.org wrote:
 

 On Nov 29, 2012, at 1:22 AM, Stephane Nicoll stephane.nic...@gmail.com
 wrote:
  I would go for 2.2. Releasing something and then include it as the
 default
  version the same day seems a bit too much for me.

 I would agree with this.  The fact that I was the first one to even
 notice
 that 2.3 has issues on the Mac suggests it's not very widely tested.  :-(

 
 I'm using it and noticed this annoying icon but I though it was related to
 some tests executions.
 What I would like is to release a 2.3.1 ASAP if everybody is agree

I'll deploy a new XStream SNAPSHOT this evening, where you might test if 
this problem still occurs.

 After that I agree to not put it in 3.1 if we have too many doubts about
 its quality


 Much like the compiler plugin, I'd let this bake a little more before
 making it the default.

 
 +1
 Using it too but I didn't find nor good nor bad changes about it. In my
 case the new incremental stuff is never called thus it works like before.

Cheers,
Jörg


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

Re: [VOTE] Maven 3.1.0

[Jörg Schaible]

Sorry guys, but I have massive internet problems this evening. It took me 
minutes to commit a little patch for this problem. So, if anyone want to 
give it a try, simply checkout XStream trunk and build on your own, my wire 
is nearly dead.

Jörg Schaible wrote:

 Hi Arnaud and Dan,
 
 Arnaud Héritier wrote:
 
 On Thu, Nov 29, 2012 at 3:41 PM, Daniel Kulp dk...@apache.org wrote:
 

 On Nov 29, 2012, at 1:22 AM, Stephane Nicoll stephane.nic...@gmail.com
 wrote:
  I would go for 2.2. Releasing something and then include it as the
 default
  version the same day seems a bit too much for me.

 I would agree with this.  The fact that I was the first one to even
 notice
 that 2.3 has issues on the Mac suggests it's not very widely tested. 
 :-(

 
 I'm using it and noticed this annoying icon but I though it was related
 to some tests executions.
 What I would like is to release a 2.3.1 ASAP if everybody is agree
 
 I'll deploy a new XStream SNAPSHOT this evening, where you might test if
 this problem still occurs.
 
 After that I agree to not put it in 3.1 if we have too many doubts about
 its quality


 Much like the compiler plugin, I'd let this bake a little more before
 making it the default.

 
 +1
 Using it too but I didn't find nor good nor bad changes about it. In my
 case the new incremental stuff is never called thus it works like before.
 
 Cheers,
 Jörg



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

Re: [VOTE] Maven 3.1.0

[Jörg Schaible]

Hi

Jörg Schaible wrote:

 
 Sorry guys, but I have massive internet problems this evening. It took me
 minutes to commit a little patch for this problem. So, if anyone want to
 give it a try, simply checkout XStream trunk and build on your own, my
 wire is nearly dead.
 
 Jörg Schaible wrote:
 
 Hi Arnaud and Dan,
 
 Arnaud Héritier wrote:
 

[snip]

 I'm using it and noticed this annoying icon but I though it was related
 to some tests executions.
 What I would like is to release a 2.3.1 ASAP if everybody is agree
 
 I'll deploy a new XStream SNAPSHOT this evening, where you might test if
 this problem still occurs.

OK, my internet is back again and the new SNAPSHOT is available.

[snip]

- Jörg


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

Re: https://jira.codehaus.org/browse/MNG-1304

[Jörg Schaible]

Jason van Zyl wrote:

 This is a long-standing issue, but I think a document and standard has
 emerged that I think is reasonable. How do people feel about trying to
 adhere to:
 
 http://semver.org
 
 and moving toward using this as our standard versioning documentation?

Well, it sounds nice, but look at Apache commons and you'll see that it 
fails in practice regarding X. If we had gone from 
org.apache.commons:commons-lang:2.2.1 to org.apache.commons:commons-
lang:3.0.0 we would have been all into jar hell. Therefore a change in X in 
Apache commons means new artifactId and new package name (if we cannot 
provide compatible APIs) to allow 2.x and 3.x version to be used side-by-
side (in classpath and as dependency).

Just my 2¢,
Jörg


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

Re: Tentative release planning for 3.1.x

[Jörg Schaible]

Hi,

personally I'd like to see at least one 3.x release that is again able to 
calculate a proper build sequence. M3 is broken in this regard and you 
cannot even rely on its results, because it uses and packs stale SNAPSHOTs. 
Therefore we're still locked to M221. However, first plugins start to 
*require* M3 and it is getting more than annoying now.

MNG-5207[5] [Regression] Maven 3 fails to calculate proper build order

After reporting this the first time, Jason requested [6] to turn the example 
project into an IT, which has been done some time ago [7].

Maven is failing here in its core competence and it would be great if 
someone with more in-depth knowledge than me can have a look, what goes 
wrong.

[5]: https://jira.codehaus.org/browse/MNG-5207
[6]: http://www.mail-archive.com/dev@maven.apache.org/msg91470.html
[7]: http://www.mail-archive.com/dev@maven.apache.org/msg93020.html

- Jörg


Jason van Zyl wrote:

 I have more cycles now, so I'd like to propose a tentative release
 schedule for the core and get some changes pushed out.
 
 3.1.0 Release
 
 I'd like to finish the following and then do a 3.1.0 release. I don't
 think these changes should be conflated with the Eclipse Aether addition,
 or the m-s-u changes.
 
 MNG-5373[1] (Document the usage and benefits of JSR330)
 MNG-5374[2] (Fix transfer listener after the JSR330 merge)
 MNG-5375[3] (Document use of SLF4J)
 MNG-5376[4] (Account for changes between the Apple and Oracle JDKs on OSX)
 
 I'll work finish the documentation tomorrow, and some mvn launcher work on
 Monday. I'd like to try and get the ITs back to normal form. The Windows
 ITs haven't passed for a month? And I'd like to try and restore the ITs on
 OSX. Any plans there? Would anyone object if I use an OSX box racked at
 Contegix?
 
 So maybe not next week, but the week after I'd like to attempt to make a
 release with all the JSR330 and SLF4J work wrapped up. Probably let this
 bake for a couple weeks before attempting the Aether integration.
 
 3.1.1 Release
 
 MNG-5354[5] (Use Eclipse Aether 9.0.0.M1)
 
 The branch I'm using is here:
 
 https://github.com/tesla/maven-3/tree/aether
 
 3.1.2 Release
 
 The m-s-u changes? I haven't seen a branch so I'm not sure how it's going
 to be integrated. In its current form I'm a little concerned that it's not
 really a drop-in replacement, but I'll follow up with another email as not
 to conflate the threads.
 
 
 
 [1]: https://jira.codehaus.org/browse/MNG-5373
 [2]: https://jira.codehaus.org/browse/MNG-5374
 [3]: https://jira.codehaus.org/browse/MNG-5375
 [4]: http://jira.codehaus.org/browse/MNG-5376
 [5]: https://jira.codehaus.org/browse/MNG-5354
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder  CTO, Sonatype
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 Simplex sigillum veri. (Simplicity is the seal of truth.)



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

Re: How to find out if a dependency is a Maven plugin?

[Jörg Schaible]

Hi Sascha,

Sascha Vogt wrote:

 Hi,
 
 Am 27.09.2012 18:42, schrieb Jörg Schaible:
 In M3 the plugins are no longer shared within the reactor i.e. each
 plugin is using its own classloader and can therefore have any arbitrary
 dependency. So if your plugin depends on another plugin, there should be
 no difference to any other dependency. However, I never tried this in M3
 and I have therefore no idea how the plugin-plugin will actually react
 when you build yours.
 So this still leaves the question, how does one find out the real type
 of a dependency (aka is this dependency a maven-plugin).
 
 Regarding the real problem we found a simpler solution. We intended to
 extend the maven-jaxb2-plugin and found that they themself use Mojo
 inheritance across different plugins. They do so, by not using xdoclet
 annotations for the parameters but real annotations and the
 maven-plugin-tools-anno [0]

You're aware that modern Maven plugins use now real annotations themselves?

 
 With the same approach we were able to extend our Mojos as well, so for
 M3 this seems to be a workable solutions.
 
 For M2, we might have to think about it - but probably (as this is only
 used in a very controlled environment) we can live with the restriction
 to only ever reference one version of any given plugin, thus eliminating
 the risk of incompatible versions being referenced in different places.

Actually we found out about this problem the hard way, because we used the 
xdoclet-plugin that depends on an ancient antrun-plugin ...

Cheers,
Jörg


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

Re: How to find out if a dependency is a Maven plugin?

[Jörg Schaible]

Hi Sascha,

Sascha Vogt wrote:

 Hi all,
 
 I currently have a small issue with upgrading to Maven 3 and a custom
 mojo I wrote.
 
 I need to find out if the dependency is a Maven plugin. With Maven 2.x
 one could check the type by comparing Artifact.getType() to
 maven-plugin. With Maven 3 this returns now jar instead of
 maven-plugin.
 Is there any other way to find out if a dependency is a Maven plugin?
 Any pointers to the API would be greatly appreciated!
 
 E.g. up to Maven 3 this code did work:
 
 MavenProject prj = ...
 for(Iterator i = prj.getDependencyArtifacts().iterator(); i.hasNext();)
 {
Artifact artifact = (Artifact) i.next();
if( maven-plugin.equals( artifact.getType() ) ) {
   //do some specific stuff
}
 }

Why do you want to know? In M2 a plugin should never be a dependency of 
another one anyway, because you will face all kind of unexpected effects due 
to the different classloader model.

- Jörg


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

Re: How to find out if a dependency is a Maven plugin?

[Jörg Schaible]

Chris Graham wrote:

 Really?
 
 A plugin can not/should not use another plugin as a dep?
 
 So how is the archiver used? Extended?

The archiver is not a plugin, it is a component that is used by a lot of 
plugins.

- Jörg


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

Re: How to find out if a dependency is a Maven plugin?

[Jörg Schaible]

Sascha Vogt wrote:

 Am 27.09.2012 15:07, schrieb Jörg Schaible:
 Sascha Vogt wrote:
 I need to find out if the dependency is a Maven plugin. With Maven 2.x
 one could check the type by comparing Artifact.getType() to
 maven-plugin. With Maven 3 this returns now jar instead of
 maven-plugin.
 Is there any other way to find out if a dependency is a Maven plugin?
 Any pointers to the API would be greatly appreciated!
 [snip]
 
 Why do you want to know? In M2 a plugin should never be a dependency of
 another one anyway, because you will face all kind of unexpected effects
 due to the different classloader model.
 The idea was to have one Mojo extend another Mojo.

In M2, it is simply not reliable and should therefore never be done.

 There is also a
 maven-inherit-plugin out there
 (https://github.com/ops4j/org.ops4j.pax.construct/tree/master/maven-
inherit-plugin)
 which suffers from the same issue.

Yes, I complained about that before.

 What do you mean by different classloader model?

M3 uses isolated classloaders for the individual plugins.

M2 will load every plugin once and only once. If you plugin depends on 
plugin x in version 2.x, but it is used elsewhere in the reactor in version 
1.x, it depends on the build sequence, which version is actually used - 
point is that your plugin has absolutely no control over version of the 
depending plugin - never. The inherit-plugin is therefore the best candidate 
to break every big multi-project build in subtle ways. You have been warned!

- Jörg



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

Re: How to find out if a dependency is a Maven plugin?

[Jörg Schaible]

Sascha Vogt wrote:

 First of all, thank you very much for the explanation. I wasn't aware of
 that up to know. Will definitely look into a different solution.
 Nevertheless I want to understand a bit more to evaluate possible ways
 to go.
 
 Am 27.09.2012 16:06, schrieb Jörg Schaible:
 Am 27.09.2012 15:07, schrieb Jörg Schaible:
 Sascha Vogt wrote:
 The idea was to have one Mojo extend another Mojo.
 In M2, it is simply not reliable and should therefore never be done.
 Ok, for M2 the stuff we did is bad :) For now let's concentrate on M3
 
 There is also a
 maven-inherit-plugin out there
 (https://github.com/ops4j/org.ops4j.pax.construct/tree/master/maven-
 inherit-plugin)
 which suffers from the same issue.
 
 Yes, I complained about that before.
 
 What do you mean by different classloader model?
 
 M3 uses isolated classloaders for the individual plugins.
 So with the isolated classloaders the extension of a plugin could/should
 work as expected (aka even if there are multiple different versions
 referenced)? Or do you mean that in M3 if I extend plugin a, my plugin
 shouldn't see classes from plugin a?

In M3 the plugins are no longer shared within the reactor i.e. each plugin 
is using its own classloader and can therefore have any arbitrary 
dependency. So if your plugin depends on another plugin, there should be no 
difference to any other dependency. However, I never tried this in M3 and I 
have therefore no idea how the plugin-plugin will actually react when you 
build yours.

- Jörg


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