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&version=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,
> 
> 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 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 , 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,
> 
>  >
>> = %< =
>> $ 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]

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 :
>> 
>>> 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: [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 :
> 
>> 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=12316922&version=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]

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=12316922&version=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: 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:
> 
> 
>   ${java.version}
>   ${java.version}
> 
> 
> 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 
> 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
>> :
>>
>>> 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  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 
> wrote:
> 
>> RTC uses Backlog. Does Jira have something similar?
>>
>> Sent from my iPhone
>>
>> On 27/11/2014, at 8:13 AM, David Jencks 
>> 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 > > 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 > > 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
>> 
>> >>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> >>>
>> >>>
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
>> For additional commands, e-mail: dev-h...@maven.apache.org 
>>
>>
> 



-
To unsubscribe, e-mail: 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:

> I think I know the problem.
> 
> Current master creates multiple MavenProject instances for the same
> parent pom, while 3.0.5 reused the same instance. I have not looked how
> hard this will be to fix yet.
> 
> In, more generally, MavenProject implementation is far from efficient.
> For example, each instance holds two copies of project Model and
> absolutely no model element reuse. For example, the same 
> element defined in a parent pom will be represented as distinct object
> instance in each child project. This is something we've known in m2e for
> long time, but optimizing this will quite tricky especially if we want
> to maintain backwards compatibility and keep model instances mutable.

thanks again for taking the time. Something must have gone wrong for an 
increased memory usage by 400% for the same stuff.

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

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

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: 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: 's

[Jörg Schaible]

Hi Mark,

Mark Derricutt wrote:

> In last weeks dev hangout I raised the idea of removing 
> 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  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  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
> `` as a `` 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  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]

Jason van Zyl wrote:

> On Apr 7, 2014, at 3:19 AM, Jörg Schaible 
> 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: [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]

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: [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  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: [VOTE] Maven 2.x is end of life

[Jörg Schaible]

Daniel Kulp wrote:

> 
> On Feb 13, 2014, at 11:18 AM, Stephen Connolly
>  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]

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

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:
>>> 
>>> com.example
>>> my-android-lib
>>> 1.0.0
>>> aar
>>> 
>>>
>>> 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.
>>> 
>>> com.example
>>> my-android-lib
>>> 1.0.0
>>> jar
>>> 
>>
>> Use a classifier ... e.g. "classes".
> 
> You are misunderstanding Joerg.

No. You have

=== %< ===

 com.example
 my-android-lib
 1.0.0
 aar
 provided 


 com.example
 my-android-lib
 1.0.0
 jar
 system
 classes
 ${basedir}/target/extracted/classes.jar

=== %< ===

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: 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:
> 
> com.example
> my-android-lib
> 1.0.0
> aar
> 
> 
> 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.
> 
> com.example
> my-android-lib
> 1.0.0
> jar
> 

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: 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  tag is not in the  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:

 ..

- 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 10:55, Jörg Schaible 
> wrote:
> 
>> Hi Stephen,
>>
>> In consequence this will also implicitly drop (transitive) dependency
>> manipulations with profiles.
>>
>>
> Yes, a "good thing" in my opinion ;-)

Definitely, although I'd love to adjust sometimes dependencies based on the 
target JDK. Nevertheless, the current profile mechanism is not usable for 
dependencies.

>> However, all makes sense now to me - thanks for explaining.
>>
> 
> Just my vision... I don't have any greater authority than any other
> committer with respect to the direction we actually end up choosing to
> follow... but that is how I thing we could square the circle...

It's definitely a step into the right direction to move forward with the 
least impact on existing stuff.

- 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
> wrote:
> 
>> On 27 August 2013 09:00, Jörg Schaible
>> wrote:
>>
>>> > 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:
> 
> 
>   4.0.0
>   
> localdomain.example
> parent
> 1.0-SNAPSHOT
>   
>   child
>   
> 4.0
>   
>   
> 
>   junit
>   junit
>   ${junit.version}
> 
>   
> 
> 
> When that gets deployed *by mvn4*, we could be deploying:
> 
> * child-1.0-SNAPSHOT.pom
> 
> 
>   4.0.0
>   localdomain.example
>   child
>   1.0-SNAPSHOT
>   
> 
>   junit
>   junit
>   4.0
> 
>   
> 
> 
> * 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:

> On 26 August 2013 08:27, Jörg Schaible 
> 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
>> >  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 , ,
> ,  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:

[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
>  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  wrote:
>> On 14 August 2013 21:21, Dennis Lundberg  wrote:
>>> On Wed, Aug 14, 2013 at 10:47 AM, sebb  wrote:
>>>
 On 13 August 2013 18:58, Dennis Lundberg  wrote:
 > On Tue, Aug 13, 2013 at 12:30 AM, sebb  wrote:
 >> On 12 August 2013 20:10, Jason van Zyl  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 ]".

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 
> 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 "" 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 /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
 > 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] 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: [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
> wrote:
> 
>> 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: Desupport Maven 1

[Jörg Schaible]

Olivier Lamy wrote:

> 2013/4/19 Brett Porter :

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

 
   ...
   
  com.example
  bundle
  1.0.1
   
   
  com.example
  bundle
  1.0.1
  features
  xml
   
   ...
 
 ...
 
   ...
   
99
   
true
   ...
 

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

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: [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  wrote:
>> 
>>>
>>> On Nov 29, 2012, at 1:22 AM, Stephane Nicoll 
>>> 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 Arnaud and Dan,

Arnaud Héritier wrote:

> On Thu, Nov 29, 2012 at 3:41 PM, Daniel Kulp  wrote:
> 
>>
>> On Nov 29, 2012, at 1:22 AM, Stephane Nicoll 
>> 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: 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]

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

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