AW: Apachecon in budapest ?

[Christofer Dutz]

Hi,

I have to admit I enjoy the meetups with other Apache guys most. Especially the 
talks you have in the Hotel lobby after the sessions have ended or on one of 
the numerous after-conference events (Usually a booth crawl and some sponsored 
evening events will take place). 

When attending to the normal conference program you usually get what you 
expect, as you select the talks according to your interests. But it's the 
evening events you get to know other Apache guys and end up with tons of new 
ideas and projects you never heard of and want to start investing your time in. 

Usually after the third conference day are workshos and a brainstorming 
get-together-unconference-thingy where you discuss all sorts of Apache related 
things with other Apache guys that I wouldn't want to miss. The ApacheCon US 
2014 was the first time I visited the Un-Conference and it was absoluteley 
worth the time.

My recommendation is to take the offer to stay in the conference hotel and to 
stay at least for the fourth day at the ApacheCon.

Chris



-Ursprüngliche Nachricht-
Von: Hervé BOUTEMY [mailto:herve.bout...@free.fr] 
Gesendet: Dienstag, 29. Juli 2014 21:51
An: Maven Developers List
Betreff: Re: Apachecon in budapest ?

it's my first ApacheCon too, so I don't have any experience either

Any feedback from other appreciated

Regards,

Hervé

Le mardi 29 juillet 2014 09:06:40 Kristian Rosenvold a écrit :
 Looking at the schedule
 (http://events.linuxfoundation.org/events/apachecon-europe/program/sch
 edule) I realized this conference is basically monday-wednesday, which 
 is good because I find a full week of conference attendance too much. 
 I have some other engagements on the specific monday which I need to 
 reschedule, which can't be done until mid-august. So negociations are 
 forthcoming :)
 
 Does anyone know if there are any specific scheduling constraints that 
 are customary at apachecon ? (Like don't miss the party on wednesday 
 night...). I figured I'd arrive early on sunday to do some tourism
 - (i hear there's a lot of nice pubs in budapest.)
 
 Kristian
 
 2014-07-24 23:09 GMT+02:00 Hervé BOUTEMY herve.bout...@free.fr:
  good news: after some negociations, I now can say that *I'll be 
  there!*
  
  Let's plan some meeting and hope we can get something shareable with 
  the whole Maven devs community
  
  Regards,
  
  Hervé
  
  Le jeudi 12 juin 2014 07:38:18 Hervé BOUTEMY a écrit :
  I'd like to try to attend too: not sure I'll be able, need to study 
  more precisely the cost (which will be high, I already know it)
  
  face to face can help
  
  more frequent hangouts are a good idea too: combining both would be 
  ideal
  :)
  
  Regards,
  
  Hervé
  
  Le mercredi 11 juin 2014 11:08:47 Tamás Cservenák a écrit :
   +1
   
   thanks,
   ~t~ (mobile)
   On Jun 11, 2014 7:54 AM, Kristian Rosenvold
   kristian.rosenv...@gmail.com
   
   wrote:
I've been considering attending apachecon in Budapest, and I 
would be really interested in creating a meet up to discuss future 
maven
(for
one or more days). It would be interesting to see if we'd be 
capable of using such an occasion to determine a little more 
about the big picture future of maven, possibly even discuss a 
proper 4.0
release
and/or work through the reality of revised pom 
versions/formats. Like a lot of us I seem to be having trouble 
finding time for more than incremental (minor) improvements. It 
also seems like a lot of the stuff on the current 4.0 list is 
quite minor stuff and I'd really enjoy an occasion to 
investigate big changes :)

Anyone else interested ?

Kristian

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


-
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

Version conflicts with guava library

[Christofer Dutz]

Hi,

I'm currently working on a plugin for the Apache Flex compiler Falcon. This 
uses Guava in a version above 15.
Now maven seems to come with a Guava version ... 0.9.9 for Maven 3.0.x, 
something about 11 for 3.1 and above.
The problem is that from version 15 on there was an API change Falcon depends 
upon. No matter what I tried, I always get an error during runtime that:

Caused by: java.lang.NoSuchMethodError: 
com.google.common.cache.CacheBuilder.build(Lcom/google/common/cache/CacheLoader;)Lcom/google/common/cache/LoadingCache;

Because till version 15 the return type was Cache and not LoadinCache.

Now to my question ... if I use a library that Maven itself comes with ... is 
there a way to use that version? Currently it seems I would require my users to 
update to Maven 3.2.x which will definitely make some pretty unhappy.

Chris

AW: Version conflicts with guava library

[Christofer Dutz]

Hi Igor,

well I currently don't have a small example ... Flexmojos as the Pluin is a 
pretty large beast and Falcon isn't a trivial example.

But I have been investigating this problem a little more and eventually the 
problems comes from how Flexmojos is built.
Currently the plugin is built using the same mechanisms used in Maven 3.0 and 
hereby relying heavily on Plexus. It seems a guice migration layer had been 
added but the whole thing seems to be built and running in some sort of 
compatability mode. Eventually I should rewrite Flexmojos to guice and more 
modern maven versions (I am having a quite some trouble with Maven versions 
greater than 3.1)

But if you say that even if Maven comes with one version, a plugin should be 
able to work with another, then that's good enough for me, I'll start migrating 
Flexmojos.

Chris


-Ursprüngliche Nachricht-
Von: Igor Fedorenko [mailto:i...@ifedorenko.com] 
Gesendet: Freitag, 3. Oktober 2014 21:59
An: dev@maven.apache.org
Betreff: Re: Version conflicts with guava library

What version of Maven do you use? Can you provide a small standalone example 
that demonstrate the problem? Like a sample plugin with a trivial demo project, 
for example.

Generally, each Maven plugin runs in its own classloader with only subset of 
Maven core classes available to it. Guava is not part of that subset and 
plugins should be able to use whatever version of Guava they like.

--
Regards,
Igor

On 2014-10-03, 15:46, Christofer Dutz wrote:
 Hi,

 I'm currently working on a plugin for the Apache Flex compiler Falcon. This 
 uses Guava in a version above 15.
 Now maven seems to come with a Guava version ... 0.9.9 for Maven 3.0.x, 
 something about 11 for 3.1 and above.
 The problem is that from version 15 on there was an API change Falcon depends 
 upon. No matter what I tried, I always get an error during runtime that:

 Caused by: java.lang.NoSuchMethodError: 
 com.google.common.cache.CacheBuilder.build(Lcom/google/common/cache/Ca
 cheLoader;)Lcom/google/common/cache/LoadingCache;

 Because till version 15 the return type was Cache and not LoadinCache.

 Now to my question ... if I use a library that Maven itself comes with ... is 
 there a way to use that version? Currently it seems I would require my users 
 to update to Maven 3.2.x which will definitely make some pretty unhappy.

 Chris




-
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

Plugin mechanism for the ConflictResolver?

[Christofer Dutz]

Hi,

Im currently struggling with some changes introduced with Maven 3.1 explicitly 
regarding the ConflictResolver in conjunction with custom scopes.
I know that these are generally not supported, but they had been working nicely 
for years. With Maven 3.1 it seems the scope of transitive dependencies of 
custom scope artifacts are all flattened to runtime.

Now to me it seems as if it were possible to support custom scopes by making 
the ConflictResolver modularizable. Currently all rules are hard-coded. How 
about defining an interface in which, in case of a custom scope maven will 
sonsult a ConflictResolver registered for that type of scope. This way plugins 
not designed for building Java applications could define how to deal with 
transitive dependencies of custom scopes?

What do you think? Am I missing something here? Would I start hurting Kittens 
again ;-) ?

Chris

AW: Plugin mechanism for the ConflictResolver?

[Christofer Dutz]

While looking for the answer to your question, I noticed that the 
ConflictResolver seems to be using the JavaScopeDeriver which is of type 
ScopeDeriver to implement the scope derivation. It seems the JavaScopeDerives 
is the only implementation of ScopeDeriver. It seems that this is all part of 
Aether. So let me rephrase my question:

Would it be possible to add additional ScopeResolvers to Aether?

Chris

-Ursprüngliche Nachricht-
Von: Hervé BOUTEMY [mailto:herve.bout...@free.fr] 
Gesendet: Samstag, 18. Oktober 2014 12:41
An: Maven Developers List
Betreff: Re: Plugin mechanism for the ConflictResolver?

Hi,

I'm not an expert from that, but I'm interested to learn: will need some 
pointers and probably unit tests.

I have one key thought: do you know if it is done at Maven level (like in Maven 
2.x) or at Aether-level?

Regards,

Hervé

Le samedi 18 octobre 2014 08:52:34 Christofer Dutz a écrit :
 Hi,
 
 Im currently struggling with some changes introduced with Maven 3.1 
 explicitly regarding the ConflictResolver in conjunction with custom 
 scopes. I know that these are generally not supported, but they had 
 been working nicely for years. With Maven 3.1 it seems the scope of 
 transitive dependencies of custom scope artifacts are all flattened to 
 runtime.
 
 Now to me it seems as if it were possible to support custom scopes by 
 making the ConflictResolver modularizable. Currently all rules are 
 hard-coded. How about defining an interface in which, in case of a 
 custom scope maven will sonsult a ConflictResolver registered for that 
 type of scope. This way plugins not designed for building Java 
 applications could define how to deal with transitive dependencies of custom 
 scopes?
 
 What do you think? Am I missing something here? Would I start hurting 
 Kittens again ;-) ?
 
 Chris


-
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

AW: AW: Plugin mechanism for the ConflictResolver?

[Christofer Dutz]

Well actually I had an even deeper look at it ... so Aether takes the 
ScopeResolver it is provided with and the JavaScopeResolver is instantiated by 
Maven code. So we could do this here ... Create a MoularizedScopeResolver that 
has a JavaScopeResolver as default . But I'll create another mail and cross 
post that to here and the Aether list.

Chris

-Ursprüngliche Nachricht-
Von: Hervé BOUTEMY [mailto:herve.bout...@free.fr] 
Gesendet: Samstag, 18. Oktober 2014 13:40
An: Maven Developers List; aether-...@eclipse.org
Betreff: Re: AW: Plugin mechanism for the ConflictResolver?

this is a question for Aether :)

I'm not an Aether expert, can't really answer

But please cross-post, because this is interesting for everybody.

Regards,

Hervé

Le samedi 18 octobre 2014 11:23:28 Christofer Dutz a écrit :
 While looking for the answer to your question, I noticed that the 
 ConflictResolver seems to be using the JavaScopeDeriver which is of 
 type ScopeDeriver to implement the scope derivation. It seems the 
 JavaScopeDerives is the only implementation of ScopeDeriver. It seems 
 that this is all part of Aether. So let me rephrase my question:
 
 Would it be possible to add additional ScopeResolvers to Aether?
 
 Chris
 
 -Ursprüngliche Nachricht-
 Von: Hervé BOUTEMY [mailto:herve.bout...@free.fr]
 Gesendet: Samstag, 18. Oktober 2014 12:41
 An: Maven Developers List
 Betreff: Re: Plugin mechanism for the ConflictResolver?
 
 Hi,
 
 I'm not an expert from that, but I'm interested to learn: will need 
 some pointers and probably unit tests.
 
 I have one key thought: do you know if it is done at Maven level (like 
 in Maven 2.x) or at Aether-level?
 
 Regards,
 
 Hervé
 
 Le samedi 18 octobre 2014 08:52:34 Christofer Dutz a écrit :
  Hi,
  
  Im currently struggling with some changes introduced with Maven 3.1 
  explicitly regarding the ConflictResolver in conjunction with custom 
  scopes. I know that these are generally not supported, but they had 
  been working nicely for years. With Maven 3.1 it seems the scope of 
  transitive dependencies of custom scope artifacts are all flattened 
  to runtime.
  
  Now to me it seems as if it were possible to support custom scopes 
  by making the ConflictResolver modularizable. Currently all rules 
  are hard-coded. How about defining an interface in which, in case of 
  a custom scope maven will sonsult a ConflictResolver registered for 
  that type of scope. This way plugins not designed for building Java 
  applications could define how to deal with transitive dependencies 
  of custom scopes?
  
  What do you think? Am I missing something here? Would I start 
  hurting Kittens again ;-) ?
  
  Chris
 
 -
 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

Pluggable ScopeResolver?

[Christofer Dutz]

Hi,

sorry for cross posting this to the maven and the aether dev-list, but my 
question is sort of cross-cutting and I don't quite know where it fits best.

I maintain the Flexmojos plugin, a maven plugin for building Apache Flex 
applications. In this we allways have had some custom scopes for managing how 
the dependencies are linked.
Ths has worked fine until Maven 3.1. Since then it seems that a ScopeResolver 
tries to handle out the transitive scopes of transitive artifacts. Now 
something has changed here. In Flex we have a scope called rsl which tells 
the compiler to use a runtime-shared-library (sort of dynamic linking against a 
dll, in contrast to the default that does static linking). While with maven 3.0 
my transitive scopes were all compile they are now runtime.

While tracking down my problem, I noticed all is related to the 
JavaScopeResolver which seems to be the only implementation of ScopeResolver. 
Having a look at the code, I think it should be easy to create some sort of 
PluggableScopeResolver, which defaults to the JavaScopeResolver. This Pluggable 
version could be used by plugins in need of custom scopes to define the logic 
for resolving their scope related issues themselves. With a feature like this, 
Flexmojos could provide a FlexScopeResolver in which I could explicitly define 
how the different types of scopes should be resolved and I would no longer have 
to sort of find workarounds to make Maven think this is actually a Java project.

I know of several Projects that would probably benefit a great deal of a 
feature like this (Flexmojos - for building Flex Applications, NPanday - for 
building C, C++, C#) and to me it wouldn't look that invasive to Maven.

I would gladly contirbute and work on this, if you guys think this would be a 
good thing to do. Perhaps someone on one of the lists has a reason for this 
using magic of the dark side of the force, but to me it looks like a sensible 
Idea ... after all, even if Maven is built in Java, I have allways understood 
it as a not only java tool.

Chris

Is there any documentation of the process of releasing an Apache project built with maven?

[Christofer Dutz]

Hi,


at the Flex project there are some parts being built with Maven. Now we would 
like to release some of them and currently there is a bit of a discussion about 
how to do this. Currently most people are insisting on a rather manual process 
they have been using for releasing the Ant built stuff.


Now I think maven could make life a lot easier for us, but I don't quite know 
how to comply to the Apache release rules. I think simply releasing the 
auto-generated source jars isn't what Apache understands as Source release.


I guess you on this list have a lot of experience with releasing Maven built 
Apache projects. Would be glad for some pointers. Searching the Maven 
Confluence page doesn't guide me to release documentations dealing with the 
requirements of the ASF and even mentioning apache maven and release swamps 
me with maven-release-plugin documentation ;-)


Would be grateful for some links or clarification.


Chris

AW: Is there any documentation of the process of releasing an Apache project built with maven?

[Christofer Dutz]

Yeah ... think this was what I was looking for. I know the maven release 
process quite well and therefore knew that probably the source-jar was not 
enough ... 

I didn't want to have to maintain an assembly config though but I was sort of 
surprised that the default config of the assembly plugin does exactly what I 
was looking for. I borrowed some plugin config from your project and I think I 
might be able to convince the others to start maven releases (Eventually even 
start converting some of the stuff to maven ;-) )

Chris


Von: Richard Eckart de Castilho r...@apache.org
Gesendet: Dienstag, 11. November 2014 10:33
An: Maven Developers List
Betreff: Re: Is there any documentation of the process of releasing an Apache 
project built with maven?

Hi Chris,

there is a quite detailed explanation of what Apache understands as a release:

  http://www.apache.org/dev/release.html

Uploading the source JARs to Maven Central is afaik not enough.
What UIMA does is, we set up the build so that as part of the Maven build,
a ZIP of the checked out sources is done starting from the root of the checkout.
It's actually pretty straight. I believe this ZIP is augmented with some
license files etc. As part of the release this source ZIP and a corresponding
ZIP containing a compiled distribution are uploaded to the Apache mirror system.

If you would like to take Apache UIMA as a role model, check out our release 
guidelines:

  http://uima.apache.org/release.html

And of course our Maven-based build setup which helps us in doing the releases
is in the Apache SVN.

Cheers,

-- Richard

On 11.11.2014, at 10:23, Christofer Dutz christofer.d...@c-ware.de wrote:

 Hi,

 at the Flex project there are some parts being built with Maven. Now we would 
 like to release some of them and currently there is a bit of a discussion 
 about how to do this. Currently most people are insisting on a rather manual 
 process they have been using for releasing the Ant built stuff.

 Now I think maven could make life a lot easier for us, but I don't quite know 
 how to comply to the Apache release rules. I think simply releasing the 
 auto-generated source jars isn't what Apache understands as Source release.

 I guess you on this list have a lot of experience with releasing Maven built 
 Apache projects. Would be glad for some pointers. Searching the Maven 
 Confluence page doesn't guide me to release documentations dealing with the 
 requirements of the ASF and even mentioning apache maven and release swamps 
 me with maven-release-plugin documentation ;-)

 Would be grateful for some links or clarification.

 Chris


-
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

Problems updating to Maven x >= 3.1.1

[Christofer Dutz]

Hi,


I am currently trying to fix a problem with the newly open-sourced Flex plugin 
for IntelliJ.


In this plugin usually a goal of a maven plugin (Flexmojos) is executed 
programmatically in order to generate a config file, which IntelliJ then uses 
to configure itself. For this they manually construct a PlexusContainer and use 
that to do all sorts of magic.


The problem is that when updating Flexmojos 7.1.0-SNAPSHOT I had to make it 
depend on at least Maven 3.1.1 as some of the resource resolution stuff had 
changed there. Unfortunately If I use anything above 3.1.0 the IntelliJ plugin 
doesn't work and it gives me this Error:


[main] WARN Sisu - Error injecting: 
org.apache.maven.plugin.DefaultBuildPluginManager
com.google.inject.ProvisionException: Guice provision errors:

1) No implementation for 
org.apache.maven.execution.scope.internal.MojoExecutionScope was bound.
  while locating org.apache.maven.plugin.DefaultBuildPluginManager

I get this when looking up "Maven":

org.apache.maven.Maven maven = 
plexusContainer.lookup(org.apache.maven.Maven.class);

The method doing this actually wants to create a RepositorySystemSession ... so 
eventually there is a different way, than to get the maven instance and then 
call newRepositorySession on that.


I know that inside maven there actually is no longer a real classic plexus 
container running ... so eventually it would be better to use Guice instead. 
Any pointers towards how to programmatically get a RepositorySystemSession 
would be great ;-)


Chris

AW: Problems updating to Maven x >= 3.1.1

[Christofer Dutz]

Ok ... so it turned out that I was the plexus container being initialized, 
didn't have any component available, I had to tell it to do a classpath scan 
and now my code is working. 

Chris


Von: Christofer Dutz <christofer.d...@c-ware.de>
Gesendet: Samstag, 17. Oktober 2015 07:45
An: dev@maven.apache.org
Betreff: Problems updating to Maven x >= 3.1.1

Hi,


I am currently trying to fix a problem with the newly open-sourced Flex plugin 
for IntelliJ.


In this plugin usually a goal of a maven plugin (Flexmojos) is executed 
programmatically in order to generate a config file, which IntelliJ then uses 
to configure itself. For this they manually construct a PlexusContainer and use 
that to do all sorts of magic.


The problem is that when updating Flexmojos 7.1.0-SNAPSHOT I had to make it 
depend on at least Maven 3.1.1 as some of the resource resolution stuff had 
changed there. Unfortunately If I use anything above 3.1.0 the IntelliJ plugin 
doesn't work and it gives me this Error:


[main] WARN Sisu - Error injecting: 
org.apache.maven.plugin.DefaultBuildPluginManager
com.google.inject.ProvisionException: Guice provision errors:

1) No implementation for 
org.apache.maven.execution.scope.internal.MojoExecutionScope was bound.
  while locating org.apache.maven.plugin.DefaultBuildPluginManager

I get this when looking up "Maven":

org.apache.maven.Maven maven = 
plexusContainer.lookup(org.apache.maven.Maven.class);

The method doing this actually wants to create a RepositorySystemSession ... so 
eventually there is a different way, than to get the maven instance and then 
call newRepositorySession on that.


I know that inside maven there actually is no longer a real classic plexus 
container running ... so eventually it would be better to use Guice instead. 
Any pointers towards how to programmatically get a RepositorySystemSession 
would be great ;-)


Chris

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

Extending Mavens Dependency-Resolution Strategy?

[Christofer Dutz]

Hi,


I am working on a new Maven plugin for building Apache Flex projects. While the 
Flexmojos plugin I am also maintaining seems to still be working but requiring 
more and more hacks, I would like to drop that and make things cleaner in a new 
plugin.


The dependency scopes defined in Maven per default are tightly linked to Javas 
scopes. Unfortunately other languages tend to have more scopes. Flex for 
example compiles in code that is directly referenced to the output and had 
so-called "rsl" scope which results in something more similar to jars or DLLs. 
The opposite -"include" - results in something like static linking, including 
all (not only the referenced code parts).


Maven accepts scopes like this but outputs a warning in the beginning. I can 
live with that. In older versions of Maven if think unknown scopes were handled 
as "compile" scope, but this was fixed and in more recent versions I think all 
scopes of transitive dependencies that are not built in to maven automatically 
resolve to runtime or provided (Don't quite remember).


I know I could get rid of the warnings by providing a custom ModelValidator, 
but I guess the resolutions of dependencies would still not work correctly.


Is there an extension point where I could provide a ".mvn/extensions.xml" entry 
to tell Maven how to resolve the other scopes? I think I stumbled over the 
component implementing the transitive resolutions one or two years ago, but I 
seem to be unable to find that again. I was planning on extending that 
component to work only on flex-type projects and to default back to the default 
if it's not a flex project.


Any other ideas, pointers, suggestions?


Chris

AW: Extending Mavens Dependency-Resolution Strategy?

[Christofer Dutz]

Hi Robert,


it definitely sounds like a first step in that direction. I added my comments 
there.

If I can help to make such a feature reality, just tell me what I should do to 
help you.


Chris


Von: Robert Scholte <rfscho...@apache.org>
Gesendet: Mittwoch, 22. Juni 2016 23:46:40
An: Maven Developers List
Betreff: Re: Extending Mavens Dependency-Resolution Strategy?

Have I look at https://issues.apache.org/jira/browse/MPLUGIN-302
This proposal will allow more scopes and plugins are able to select a set
of dependencies based on the scope.
It looks like your problem could be solved with this implementation.

thanks,
Robert

On Wed, 22 Jun 2016 10:40:41 +0200, Christofer Dutz
<christofer.d...@c-ware.de> wrote:

> Hi,
>
>
> I am working on a new Maven plugin for building Apache Flex projects.
> While the Flexmojos plugin I am also maintaining seems to still be
> working but requiring more and more hacks, I would like to drop that and
> make things cleaner in a new plugin.
>
>
> The dependency scopes defined in Maven per default are tightly linked to
> Javas scopes. Unfortunately other languages tend to have more scopes.
> Flex for example compiles in code that is directly referenced to the
> output and had so-called "rsl" scope which results in something more
> similar to jars or DLLs. The opposite -"include" - results in something
> like static linking, including all (not only the referenced code parts).
>
>
> Maven accepts scopes like this but outputs a warning in the beginning. I
> can live with that. In older versions of Maven if think unknown scopes
> were handled as "compile" scope, but this was fixed and in more recent
> versions I think all scopes of transitive dependencies that are not
> built in to maven automatically resolve to runtime or provided (Don't
> quite remember).
>
>
> I know I could get rid of the warnings by providing a custom
> ModelValidator, but I guess the resolutions of dependencies would still
> not work correctly.
>
>
> Is there an extension point where I could provide a
> ".mvn/extensions.xml" entry to tell Maven how to resolve the other
> scopes? I think I stumbled over the component implementing the
> transitive resolutions one or two years ago, but I seem to be unable to
> find that again. I was planning on extending that component to work only
> on flex-type projects and to default back to the default if it's not a
> flex project.
>
>
> Any other ideas, pointers, suggestions?
>
>
> Chris

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

AW: ACNA Vancouver 2016

[Christofer Dutz]

Don't know if you did anything, but now I can access the applications :-) 
Thanks :-)

Chris


Von: Christofer Dutz <christofer.d...@c-ware.de>
Gesendet: Samstag, 30. Januar 2016 11:25
An: Lewis John Mcgibbney; travel-assista...@apache.org; Melissa Warnkin; Maven 
Developers List
Betreff: AW: ACNA Vancouver 2016

I just created my account with the email address cd...@apache.org ... would be 
cool if you could grant me the permissions :-)


Chris



Von: Christofer Dutz <christofer.d...@c-ware.de>
Gesendet: Samstag, 30. Januar 2016 10:17
An: Lewis John Mcgibbney; travel-assista...@apache.org; Melissa Warnkin
Betreff: AW: ACNA Vancouver 2016


Hi Melissa,


well I tried to login to the tac-apply thingy, but I couldn't ... so I tried my 
apache email, my private one and my company one for a password reset, but the 
system keeps on telling me that such an account doesn't exist ... so I guess I 
need an account first ;-)


Chris



Von: Melissa Warnkin <missywarn...@yahoo.com>
Gesendet: Freitag, 29. Januar 2016 20:16
An: Lewis John Mcgibbney; travel-assista...@apache.org
Betreff: Re: ACNA Vancouver 2016

hahahaha Chris and Lewis!!! You guys crack me up!

Chris - have you tried to see if Nick has already granted you karma to be a 
judge? All you have to do is go to https://tac-apply.apache.org/ - top right 
you will see "judging", click on that.  If it doesn't pull up, you do not have 
access yet.
Apache Travel Assistance - Home<https://tac-apply.apache.org/>
tac-apply.apache.org
The Travel Assistance Committee is taking in applications for those wanting to 
attend ApacheCon NA 2016 Vancouver between May 9, 2016 and May ...



But wait.at this stage of the process, if he doesn't have judge rights, he 
shouldn't be able to even open up the applications to read them, correct? So, 
Chris, that's another way to determine if you have judge rights yet or not...if 
you can't open any of the applications, you do not have the rights yet.

Either way, first step is to get or determine judge rights for Chris...and then 
you guys should have a quick talk about the judging process so he knows the 
process.

Keep your pants on and your kilts down (and not blowing up in the wind!!)!! ;) 
Oh, and have a wonderful weekend!!

~M



From: Lewis John Mcgibbney <lewis.mcgibb...@gmail.com>
To: "travel-assista...@apache.org" <travel-assista...@apache.org>
Cc: Melissa Warnkin <missywarn...@yahoo.com>
Sent: Friday, January 29, 2016 11:50 AM
Subject: Re: ACNA Vancouver 2016

They are called Kilts I'll have you know ;)
In all honesty, the net month is pretty quiet.
I will get reminders sent out tomorrow to committers@ and pmcs@. We can also 
get press@ to send a reminder.
On top of that, the only thing we can do is to get you set up for judging 
incoming applications.
The process is pretty straightforward and we will discuss here if you have any 
issues.
Hpefully Nick can get you set up with judging karma.
Thanks Chris.

On Fri, Jan 29, 2016 at 7:21 AM, Christofer Dutz 
<christofer.d...@c-ware.de<mailto:christofer.d...@c-ware.de>> wrote:
Or for any Scottish people with their skirts down ;-)

Well as I said, I'd be glad to help ... just tell me what to do and if it's 
complicated with a little "how to do it".

Chris



Von: Melissa Warnkin <missywarn...@yahoo.com<mailto:missywarn...@yahoo.com>>
Gesendet: Donnerstag, 28. Januar 2016 21:24
An: travel-assista...@apache.org<mailto:travel-assista...@apache.org>
Betreff: Re: ACNA Vancouver 2016

Thanks, Lewis! Yes, we definitely need to re-engagethe list has been too 
quiet for my liking! :) Like I said previously, I don't want us to get caught 
with our pants downwe need to be proactively staying on top of things.

Thanks, bud!!
~M



From: Lewis John Mcgibbney 
<lewis.mcgibb...@gmail.com<mailto:lewis.mcgibb...@gmail.com>>
To: "travel-assista...@apache.org<mailto:travel-assista...@apache.org>" 
<travel-assista...@apache.org<mailto:travel-assista...@apache.org>>; Melissa 
Warnkin <missywarn...@yahoo.com<mailto:missywarn...@yahoo.com>>
Sent: Thursday, January 28, 2016 3:20 PM
Subject: Re: ACNA Vancouver 2016

Hi Missy,
I think we all need to reengage.
I'll have a pop at updating everything to the best of my ability.
Once this is done then I will write to the list with the intent of getting a 
bit of organization back into the process.
Thanks for bringing this back up.
Lewis

On Thu, Jan 28, 2016 at 10:56 AM, Melissa Warnkin 
<missywarn...@yahoo.com<mailto:missywarn...@yahoo.com>> wrote:
Is anyone keeping up on this timeline s/s, or is there a different one 
somewhere?!



From: jan i <j...

AW: ACNA Vancouver 2016

[Christofer Dutz]

Ok ... stupid me ... a new link did appear after reloading ... "applications" 
when clicking on that and selecting "Vancouver" I only got to the application 
form. So I guess I still need some Mojo to do the judging.

Chris

________
Von: Christofer Dutz <christofer.d...@c-ware.de>
Gesendet: Samstag, 30. Januar 2016 14:36
An: Lewis John Mcgibbney; travel-assista...@apache.org; Melissa Warnkin; Maven 
Developers List
Betreff: AW: ACNA Vancouver 2016

Don't know if you did anything, but now I can access the applications :-) 
Thanks :-)

Chris

____
Von: Christofer Dutz <christofer.d...@c-ware.de>
Gesendet: Samstag, 30. Januar 2016 11:25
An: Lewis John Mcgibbney; travel-assista...@apache.org; Melissa Warnkin; Maven 
Developers List
Betreff: AW: ACNA Vancouver 2016

I just created my account with the email address cd...@apache.org ... would be 
cool if you could grant me the permissions :-)


Chris


________
Von: Christofer Dutz <christofer.d...@c-ware.de>
Gesendet: Samstag, 30. Januar 2016 10:17
An: Lewis John Mcgibbney; travel-assista...@apache.org; Melissa Warnkin
Betreff: AW: ACNA Vancouver 2016


Hi Melissa,


well I tried to login to the tac-apply thingy, but I couldn't ... so I tried my 
apache email, my private one and my company one for a password reset, but the 
system keeps on telling me that such an account doesn't exist ... so I guess I 
need an account first ;-)


Chris



Von: Melissa Warnkin <missywarn...@yahoo.com>
Gesendet: Freitag, 29. Januar 2016 20:16
An: Lewis John Mcgibbney; travel-assista...@apache.org
Betreff: Re: ACNA Vancouver 2016

hahahaha Chris and Lewis!!! You guys crack me up!

Chris - have you tried to see if Nick has already granted you karma to be a 
judge? All you have to do is go to https://tac-apply.apache.org/ - top right 
you will see "judging", click on that.  If it doesn't pull up, you do not have 
access yet.
Apache Travel Assistance - Home<https://tac-apply.apache.org/>
tac-apply.apache.org
The Travel Assistance Committee is taking in applications for those wanting to 
attend ApacheCon NA 2016 Vancouver between May 9, 2016 and May ...



But wait.at this stage of the process, if he doesn't have judge rights, he 
shouldn't be able to even open up the applications to read them, correct? So, 
Chris, that's another way to determine if you have judge rights yet or not...if 
you can't open any of the applications, you do not have the rights yet.

Either way, first step is to get or determine judge rights for Chris...and then 
you guys should have a quick talk about the judging process so he knows the 
process.

Keep your pants on and your kilts down (and not blowing up in the wind!!)!! ;) 
Oh, and have a wonderful weekend!!

~M



From: Lewis John Mcgibbney <lewis.mcgibb...@gmail.com>
To: "travel-assista...@apache.org" <travel-assista...@apache.org>
Cc: Melissa Warnkin <missywarn...@yahoo.com>
Sent: Friday, January 29, 2016 11:50 AM
Subject: Re: ACNA Vancouver 2016

They are called Kilts I'll have you know ;)
In all honesty, the net month is pretty quiet.
I will get reminders sent out tomorrow to committers@ and pmcs@. We can also 
get press@ to send a reminder.
On top of that, the only thing we can do is to get you set up for judging 
incoming applications.
The process is pretty straightforward and we will discuss here if you have any 
issues.
Hpefully Nick can get you set up with judging karma.
Thanks Chris.

On Fri, Jan 29, 2016 at 7:21 AM, Christofer Dutz 
<christofer.d...@c-ware.de<mailto:christofer.d...@c-ware.de>> wrote:
Or for any Scottish people with their skirts down ;-)

Well as I said, I'd be glad to help ... just tell me what to do and if it's 
complicated with a little "how to do it".

Chris



Von: Melissa Warnkin <missywarn...@yahoo.com<mailto:missywarn...@yahoo.com>>
Gesendet: Donnerstag, 28. Januar 2016 21:24
An: travel-assista...@apache.org<mailto:travel-assista...@apache.org>
Betreff: Re: ACNA Vancouver 2016

Thanks, Lewis! Yes, we definitely need to re-engagethe list has been too 
quiet for my liking! :) Like I said previously, I don't want us to get caught 
with our pants downwe need to be proactively staying on top of things.

Thanks, bud!!
~M



From: Lewis John Mcgibbney 
<lewis.mcgibb...@gmail.com<mailto:lewis.mcgibb...@gmail.com>>
To: "travel-assista...@apache.org<mailto:travel-assista...@apache.org>" 
<travel-assista...@apache.org<mailto:travel-assista...@apache.org>>; Melissa 
Warnkin <missywarn...@yahoo.com<mailto:missywarn...@yahoo.com>>
Sent: Thursday, January 28, 2016 3:20 PM
Subject: Re: ACNA Vancouver 2016

Hi Missy,

AW: ACNA Vancouver 2016

[Christofer Dutz]

I just created my account with the email address cd...@apache.org ... would be 
cool if you could grant me the permissions :-)


Chris



Von: Christofer Dutz <christofer.d...@c-ware.de>
Gesendet: Samstag, 30. Januar 2016 10:17
An: Lewis John Mcgibbney; travel-assista...@apache.org; Melissa Warnkin
Betreff: AW: ACNA Vancouver 2016


Hi Melissa,


well I tried to login to the tac-apply thingy, but I couldn't ... so I tried my 
apache email, my private one and my company one for a password reset, but the 
system keeps on telling me that such an account doesn't exist ... so I guess I 
need an account first ;-)


Chris



Von: Melissa Warnkin <missywarn...@yahoo.com>
Gesendet: Freitag, 29. Januar 2016 20:16
An: Lewis John Mcgibbney; travel-assista...@apache.org
Betreff: Re: ACNA Vancouver 2016

hahahaha Chris and Lewis!!! You guys crack me up!

Chris - have you tried to see if Nick has already granted you karma to be a 
judge? All you have to do is go to https://tac-apply.apache.org/ - top right 
you will see "judging", click on that.  If it doesn't pull up, you do not have 
access yet.
Apache Travel Assistance - Home<https://tac-apply.apache.org/>
tac-apply.apache.org
The Travel Assistance Committee is taking in applications for those wanting to 
attend ApacheCon NA 2016 Vancouver between May 9, 2016 and May ...



But wait.at this stage of the process, if he doesn't have judge rights, he 
shouldn't be able to even open up the applications to read them, correct? So, 
Chris, that's another way to determine if you have judge rights yet or not...if 
you can't open any of the applications, you do not have the rights yet.

Either way, first step is to get or determine judge rights for Chris...and then 
you guys should have a quick talk about the judging process so he knows the 
process.

Keep your pants on and your kilts down (and not blowing up in the wind!!)!! ;) 
Oh, and have a wonderful weekend!!

~M



From: Lewis John Mcgibbney <lewis.mcgibb...@gmail.com>
To: "travel-assista...@apache.org" <travel-assista...@apache.org>
Cc: Melissa Warnkin <missywarn...@yahoo.com>
Sent: Friday, January 29, 2016 11:50 AM
Subject: Re: ACNA Vancouver 2016

They are called Kilts I'll have you know ;)
In all honesty, the net month is pretty quiet.
I will get reminders sent out tomorrow to committers@ and pmcs@. We can also 
get press@ to send a reminder.
On top of that, the only thing we can do is to get you set up for judging 
incoming applications.
The process is pretty straightforward and we will discuss here if you have any 
issues.
Hpefully Nick can get you set up with judging karma.
Thanks Chris.

On Fri, Jan 29, 2016 at 7:21 AM, Christofer Dutz 
<christofer.d...@c-ware.de<mailto:christofer.d...@c-ware.de>> wrote:
Or for any Scottish people with their skirts down ;-)

Well as I said, I'd be glad to help ... just tell me what to do and if it's 
complicated with a little "how to do it".

Chris



Von: Melissa Warnkin <missywarn...@yahoo.com<mailto:missywarn...@yahoo.com>>
Gesendet: Donnerstag, 28. Januar 2016 21:24
An: travel-assista...@apache.org<mailto:travel-assista...@apache.org>
Betreff: Re: ACNA Vancouver 2016

Thanks, Lewis! Yes, we definitely need to re-engagethe list has been too 
quiet for my liking! :) Like I said previously, I don't want us to get caught 
with our pants downwe need to be proactively staying on top of things.

Thanks, bud!!
~M



From: Lewis John Mcgibbney 
<lewis.mcgibb...@gmail.com<mailto:lewis.mcgibb...@gmail.com>>
To: "travel-assista...@apache.org<mailto:travel-assista...@apache.org>" 
<travel-assista...@apache.org<mailto:travel-assista...@apache.org>>; Melissa 
Warnkin <missywarn...@yahoo.com<mailto:missywarn...@yahoo.com>>
Sent: Thursday, January 28, 2016 3:20 PM
Subject: Re: ACNA Vancouver 2016

Hi Missy,
I think we all need to reengage.
I'll have a pop at updating everything to the best of my ability.
Once this is done then I will write to the list with the intent of getting a 
bit of organization back into the process.
Thanks for bringing this back up.
Lewis

On Thu, Jan 28, 2016 at 10:56 AM, Melissa Warnkin 
<missywarn...@yahoo.com<mailto:missywarn...@yahoo.com>> wrote:
Is anyone keeping up on this timeline s/s, or is there a different one 
somewhere?!



From: jan i <j...@apache.org<mailto:j...@apache.org>>
To: mailto:travel-assista...@apache.org
Sent: Wednesday, September 30, 2015 11:55 AM
Subject: ACNA Vancouver 2016

Hi.

After slight pressure from Nick, I have created a spreadsheet with a timeline.

Link is here:
https://docs.google.com/spreadsheets/d/1uE8F9e2SX3CnYSCf4yyN3aSqlwtLlxOG_wYaeaZIDlg/edit?usp=sharing

It seems to work out quite well, flights as usual are a bit short (just under 
60 days).

How do we continue ?

rgds
jan i





--
Lewis





--
Lewis

AW: Re[2]: MavenReport vs. true

[Christofer Dutz]

Hi Dirk,

How about making it a real maven extension? One of the ones you define in 
".mvn/extensions.xml"? 

If the JQAssistant backend was running as a real extension, I guess you 
shouldn't need to run the reporting as extension, as it could act as a client 
to that backend. I guess this should solve most class loading problems.

And it could be used to resolve some problems I'm having with "mvn clean 
install" (Currently this will fail as jqa has an open database in the 
reactor-roots target directory and the clean will fail (on windows) or will 
result with an empty database (mac & linux). 

Chris


Von: Dirk Mahler 
Gesendet: Freitag, 18. März 2016 06:21
An: Maven Developers List
Betreff: Re[2]: MavenReport vs. true

Hi Karl Heinz,

maybe I've got something wrong - short recap:

- The jQA Maven plugin provides several Mojos, some of them use an
embedded instance of Neo4j which is needs to be a singleton in the
reactor.  Therefore in some reactors it's necessary to declare the
plugin using true, i.e. if other extensions are
present
- But in this case the report Mojo isn't picked up by the site plugin
("[WARNING] ignoring ...jqassistant-maven-plugin:1.1.2:report goal since
it is not a report: should be removed from reporting configuration in
POM" -> a classloading issue
- To solve this I've tried to declare the jQA plugin declaration in the
reporting section as extension - that's not possible

Seems that the best way to get around it would be separating the report
Mojo out into another Maven plugin, e.g.
jqassistant-maven-reporting-plugin.

Best regards,

Dirk

-- Originalnachricht --
Von: "Karl Heinz Marbaise" 
An: "Maven Developers List" 
Gesendet: 17.03.2016 20:08:05
Betreff: Re: MavenReport vs. true

>Hi Dirk,
>
>Ah...
>yes the reporting does not allow extensions...
>
>You can only define an extension in the build area or explicit as
>extension
>
>
>   
>
> <...>
>
>   
>
>
>why would you like to define the plugin in the reporting as extension?
>
>Kind regards
>Karl Heinz
>
>On 3/17/16 7:57 PM, Dirk Mahler wrote:
>>Hi Karl Heinz,
>>
>>the "extensions" element is not supported in the reporting section:
>>
>>
>>
>>  
>>com.buschmais.jqassistant.scm
>>jqassistant-maven-plugin
>>1.1.2
>>true 
>>
>>  
>>
>>  report
>>
>>   
>> 
>>  
>>
>>
>>
>>Best regards,
>>
>>Dirk
>>
>>-- Originalnachricht --
>>Von: "Karl Heinz Marbaise" 
>>An: "Maven Developers List" 
>>Gesendet: 17.03.2016 18:43:30
>>Betreff: Re: MavenReport vs. true
>>
>>>Hi Dirk,
>>>
>>>On 3/16/16 9:03 PM, Dirk Mahler wrote:
Hi,

a project of mine (jQAssistant) provides Maven plugin which includes
a
Mojo for creating reports for a Maven site:

@Mojo(name = "report", defaultPhase = LifecyclePhase.SITE)
public class ReportMojo extends AbstractMavenReport {

There seems to be a problem if the Maven plugin is declared as
extension
(which sometimes is necessary to avoid classloading problems for a
Neo4j
instance acting as singleton in the reactor):


com.buschmais.jqassistant.scm
jqassistant-maven-plugin
1.1.2
true


In this case the following warning is rendered:

[WARNING] ignoring
com.buschmais.jqassistant.scm:jqassistant-maven-plugin:1.1.2:report
goal
since it is not a report: should be removed from reporting
configuration
in POM
>>>
>>>Is you plugin configured in the reporting section as well as like
>>>above?
>>>
>>>Kind regards
>>>Karl Heinz Marbaise
>>>

This warning is issued by DefaultMavenReportExecutor after passing
the
following line:

boolean isMavenReport = MavenReport.class.isAssignableFrom(
mojoClass );

Is there a way to get around that (Maven 3.3.9)?

Best regards from Dresden
>>>
>
>-
>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

AW: Classloading issues in maven plugin with custom lifecycle mapping

[Christofer Dutz]

Sure I do ... It's an Apache Project ... you could reproduce by doing the 
following:

1. Checkout apache flex falcon from 
https://git-wip-us.apache.org/repos/asf/flex-falcon.git
2. switch to the "feature/maven-migration" branch
3. run the "migrate-to-maven.sh" script which moves stuff around

Now it should be a valid Maven project.

As I use a maven extension in the ".mvn" directory, you have to have at least 
Maven 3.3.1.

I identified some modules that need to be built prior to running the build, 
after the first release I will separate them from the project as they should 
not change very often. They are built via the "minimal" profile:

mvn install -P minimal

The problem occurs if you build both of the main parts in one build:

mvn clean install -P compiler,externs -DskipTests

(You should skip the tests, as the build does have dependencies on the 
Flashplayer and skiping the tests, doesn't have an effect on the 
success/failure of the build)

You should get a CNFE when building the externs, but if you just build the 
externs (by only activating the externs profile), all is good.

Chris


Von: Robert Scholte <rfscho...@apache.org>
Gesendet: Dienstag, 12. April 2016 20:09
An: Maven Developers List
Betreff: Re: Classloading issues in maven plugin with custom lifecycle mapping

Hi,

do you have an example project (e.g. at github) to reproduce it?
Not sure if this is the issue, but maven-plugins cannot be part and used
by a multimodule project. Before a project can be built, all plugins must
be resolved. This shouldn't be an issue, since a maven-plugin should have
a different lifecycle compared to a multimodule-project using it.

thanks,
Robert

On Tue, 12 Apr 2016 15:16:01 +0200, Christofer Dutz
<christofer.d...@c-ware.de> wrote:

> Hi,
>
>
> I am currently working on converting Apache Flex from Ant to Maven. I
> have managed to convert all of the Ant stuff in our newest SDK. I even
> built a new maven plugin for doing the Flex compilation. All parts seem
> to be working great.
>
>
> The build consists of:
>
> - A compiler
>
> - Some Framework libs that are build using the compiler
>
>
> The maven plugin is not part of the build. The maven plugin has a
> plugin-dependency to the compiler artifact. It is used in the framework
> modules to build the flex artifacts.
>
>
> Now if I just build the compiler or I just build the framework, all
> works fine. But if I build compiler and framework in the same build, the
> flex maven plugin complains about not being able to find the classes of
> the compiler. The dump of the classpath lists the compiler.jar, but it
> doesn't seem to be able to load any classes from it. If I take the
> context classloader inside the plugin and create a new instance with the
> exact same URLs, I am able to manually load the class.
>
>
> I assume that this is due to the fact that the compiler jar is replaced
> during the build after getting a handle to the jar file and before using
> it. But that is just a well educated guess. Is there anything I could do
> to make this build work?
>
>
> I am also having builds randomly fail because artifacts that are used b
> plugins are replaced during the build, but I couldn't quite pin the
> problem down to a cause.
>
>
> Probably when I asked this question on the user list, this was too
> specific for that list, as I didn't get a single response. Hopefully on
> this list it will be different :-)
>
>
> I would really appreciate a little Help here ... It's definitely worth
> at least a beer in Vancouver ;-)
>
>
> Chris

-
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

Classloading issues in maven plugin with custom lifecycle mapping

[Christofer Dutz]

Hi,


I am currently working on converting Apache Flex from Ant to Maven. I have 
managed to convert all of the Ant stuff in our newest SDK. I even built a new 
maven plugin for doing the Flex compilation. All parts seem to be working great.


The build consists of:

- A compiler

- Some Framework libs that are build using the compiler


The maven plugin is not part of the build. The maven plugin has a 
plugin-dependency to the compiler artifact. It is used in the framework modules 
to build the flex artifacts.


Now if I just build the compiler or I just build the framework, all works fine. 
But if I build compiler and framework in the same build, the flex maven plugin 
complains about not being able to find the classes of the compiler. The dump of 
the classpath lists the compiler.jar, but it doesn't seem to be able to load 
any classes from it. If I take the context classloader inside the plugin and 
create a new instance with the exact same URLs, I am able to manually load the 
class.


I assume that this is due to the fact that the compiler jar is replaced during 
the build after getting a handle to the jar file and before using it. But that 
is just a well educated guess. Is there anything I could do to make this build 
work?


I am also having builds randomly fail because artifacts that are used b plugins 
are replaced during the build, but I couldn't quite pin the problem down to a 
cause.


Probably when I asked this question on the user list, this was too specific for 
that list, as I didn't get a single response. Hopefully on this list it will be 
different :-)


I would really appreciate a little Help here ... It's definitely worth at least 
a beer in Vancouver ;-)


Chris

AW: AW: Re[2]: MavenReport vs. true

[Christofer Dutz]

Hi Dirk,

I have worked with them before so I can help you ... at least this way I can 
give something back for your great support over the last few weeks with getting 
JQAssistant working at my current project ;-)

Chris


Von: Dirk Mahler 
Gesendet: Freitag, 18. März 2016 15:53
An: Maven Developers List
Betreff: Re: AW: Re[2]: MavenReport vs. true

Hi Chris,

I already had this discussion with Karl Heinz and it sounds like a good
idea. I need to have a deeper look at what this actually means (I
haven't worked with extensions so far) and how much effort it would take
to restructure things like that...

Dirk

> How about making it a real maven extension? One of the ones you define
> in ".mvn/extensions.xml"?
>
> If the JQAssistant backend was running as a real extension, I guess
> you shouldn't need to run the reporting as extension, as it could act
> as a client to that backend. I guess this should solve most class
> loading problems.
>
> And it could be used to resolve some problems I'm having with "mvn
> clean install" (Currently this will fail as jqa has an open database
> in the reactor-roots target directory and the clean will fail (on
> windows) or will result with an empty database (mac & linux).
>
> Chris
>
> 
> Von: Dirk Mahler 
> Gesendet: Freitag, 18. März 2016 06:21
> An: Maven Developers List
> Betreff: Re[2]: MavenReport vs. true
>
> Hi Karl Heinz,
>
> maybe I've got something wrong - short recap:
>
> - The jQA Maven plugin provides several Mojos, some of them use an
> embedded instance of Neo4j which is needs to be a singleton in the
> reactor.  Therefore in some reactors it's necessary to declare the
> plugin using true, i.e. if other extensions
> are
> present
> - But in this case the report Mojo isn't picked up by the site plugin
> ("[WARNING] ignoring ...jqassistant-maven-plugin:1.1.2:report goal
> since
> it is not a report: should be removed from reporting configuration in
> POM" -> a classloading issue
> - To solve this I've tried to declare the jQA plugin declaration in the
> reporting section as extension - that's not possible
>
> Seems that the best way to get around it would be separating the report
> Mojo out into another Maven plugin, e.g.
> jqassistant-maven-reporting-plugin.
>
> Best regards,
>
> Dirk
>
> -- Originalnachricht --
> Von: "Karl Heinz Marbaise" 
> An: "Maven Developers List" 
> Gesendet: 17.03.2016 20:08:05
> Betreff: Re: MavenReport vs. true
>
>> Hi Dirk,
>>
>> Ah...
>> yes the reporting does not allow extensions...
>>
>> You can only define an extension in the build area or explicit as
>> extension
>>
>> 
>>   
>>
>> <...>
>>
>>   
>> 
>>
>> why would you like to define the plugin in the reporting as extension?
>>
>> Kind regards
>> Karl Heinz
>>
>> On 3/17/16 7:57 PM, Dirk Mahler wrote:
>>> Hi Karl Heinz,
>>>
>>> the "extensions" element is not supported in the reporting section:
>>>
>>> 
>>>
>>>  
>>>com.buschmais.jqassistant.scm
>>>jqassistant-maven-plugin
>>>1.1.2
>>>true 
>>>
>>>  
>>>
>>>  report
>>>
>>>   
>>> 
>>>  
>>>
>>> 
>>>
>>> Best regards,
>>>
>>> Dirk
>>>
>>> -- Originalnachricht --
>>> Von: "Karl Heinz Marbaise" 
>>> An: "Maven Developers List" 
>>> Gesendet: 17.03.2016 18:43:30
>>> Betreff: Re: MavenReport vs. true
>>>
 Hi Dirk,

 On 3/16/16 9:03 PM, Dirk Mahler wrote:
> Hi,
>
> a project of mine (jQAssistant) provides Maven plugin which
> includes
> a
> Mojo for creating reports for a Maven site:
>
> @Mojo(name = "report", defaultPhase = LifecyclePhase.SITE)
> public class ReportMojo extends AbstractMavenReport {
>
> There seems to be a problem if the Maven plugin is declared as
> extension
> (which sometimes is necessary to avoid classloading problems for a
> Neo4j
> instance acting as singleton in the reactor):
>
> 
>com.buschmais.jqassistant.scm
>jqassistant-maven-plugin
>1.1.2
>true
> 
>
> In this case the following warning is rendered:
>
>[WARNING] ignoring
> com.buschmais.jqassistant.scm:jqassistant-maven-plugin:1.1.2:report
> goal
> since it is not a report: should be removed from reporting
> configuration
> in POM

 Is you plugin configured in the reporting section as well as like
 above?

 Kind regards
 Karl Heinz Marbaise

>
> This warning is issued by DefaultMavenReportExecutor after passing
> the
> following line:
>
>boolean isMavenReport = MavenReport.class.isAssignableFrom(
> mojoClass );
>
> Is there a way to get around that (Maven 3.3.9)?
>
> 

AW: Extending Maven to allow scope resolutions for other languages than Java

[Christofer Dutz]

So am I correct, that in order to do what I would like to, I simply have to 
wait for a while?

If not I'd be happy for some pointers.


Chris


Von: Christian Schulte <c...@schulte.it>
Gesendet: Dienstag, 19. Juli 2016 23:48:04
An: Maven Developers List
Betreff: Re: Extending Maven to allow scope resolutions for other languages 
than Java

Am 07/18/16 um 20:39 schrieb Robert Scholte:
> On Mon, 18 Jul 2016 15:54:24 +0200, Christian Schulte <c...@schulte.it>
> wrote:
>
>> Am 07/18/16 um 15:02 schrieb Christofer Dutz:
>>> Hi,
>>>
>>>
>>> Unfortuantely I wrote this down as a Jira ticket, but it seems it
>>> wasn't created in the end so I'll post this via Email ;-)
>>>
>>>
>>> I am currently working on clean support for Apache Flex build with
>>> Maven. Prior to 3.3.1 non-java builds were sort of relying on a
>>> scope-resolution bug that was fixed in newer version. Now non-default
>>> scopes can no longer have transitive dependencies. In order to fix
>>> this, I did a little refactoring of the scope resolution code in
>>> MavenRepositorySystemUtils.newSession().
>>>
>>>
>>> The idea is to wrap together the language-dependent parts of the scope
>>> resolution and have these automatically injected into
>>> DefaultRepositorySystemFactory. Per default there would only be one
>>> instance (JavaLanguageSupport) available. But I could provide other
>>> LanguageSupport implementations for other languages via Maven
>>> extensions.
>>>
>>>
>>> I implemented this as a POC. I didn't find my changes breaking anything
>>> in the maven test-suite and I was able to add my FlexJsLanguageSupport
>>> to maven and have it called for scope resolution requests.
>>>
>>>
>>> I just pushed a commit to my maven fork:
>>>
>>> https://github.com/chrisdutz/maven/commit/cd205837540c3df74ad4a8eb8b6c710a93cff156
>>>
>>> And here ist the FlexJS counterpart:
>>>
>>> https://git1-us-west.apache.org/repos/asf?p=flex-falcon.git;a=commit;h=aea14be67db2b28b766d274d900ce076fdb8522b
>>>
>>>
>>> Does it make sense to invest more time into this feature, or is this
>>> road a dead-end?
>>>
>>
>> Instead of adding that 'LanguageSupport' interface, I would go for
>> injecting the 'DependencyGraphTransformer' to use directly. No need for
>> a new interface. So that a customized 'ConflictResolver' can be injected
>> you can setup the way you want. Makes things like your
>> 'MultiLanguageScopeDeriver' part of your extension instead of Maven
>> core. I think some kind of 'DependencyGraphTransformer' extension point
>> will be provided in 3.5. Maybe there will be more than just one
>> transformer for the various classpaths. We currently resolve the project
>> artifacts once and then make Maven build the classpaths based on those
>> artifacts. In 3.5 this may be enhanced to provide various artifact
>> resolution strategies based on the classpath to build. So that
>> 'MavenProject.getCompileClasspathElements' may provide different
>> artifacts than 'MavenProject.getTestClasspathElements'. Nothing concrete
>> yet.
>>
>> Regards,
>
> I'd like to deprecate both MavenProject.getClasspathElements and
> MavenProject.getTestClasspathElements. These are too tightly bound to
> Java, whereas Maven should be language independent.

+1

And I am all for adding an interface allowing to resolve artifacts based
on something I currently don't now how to name.

Set|Tree|Node|what? resolveArtifacts(Object|String|what?
classpath|identifier|target|main|test|app|what?);

Regards,
--
Christian


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

Extending Maven to allow scope resolutions for other languages than Java

[Christofer Dutz]

Hi,


Unfortuantely I wrote this down as a Jira ticket, but it seems it wasn't 
created in the end so I'll post this via Email ;-)


I am currently working on clean support for Apache Flex build with Maven. Prior 
to 3.3.1 non-java builds were sort of relying on a scope-resolution bug that 
was fixed in newer version. Now non-default scopes can no longer have 
transitive dependencies. In order to fix this, I did a little refactoring of 
the scope resolution code in MavenRepositorySystemUtils.newSession().


The idea is to wrap together the language-dependent parts of the scope 
resolution and have these automatically injected into 
DefaultRepositorySystemFactory. Per default there would only be one instance 
(JavaLanguageSupport) available. But I could provide other LanguageSupport 
implementations for other languages via Maven extensions.


I implemented this as a POC. I didn't find my changes breaking anything in the 
maven test-suite and I was able to add my FlexJsLanguageSupport to maven and 
have it called for scope resolution requests.


I just pushed a commit to my maven fork:

https://github.com/chrisdutz/maven/commit/cd205837540c3df74ad4a8eb8b6c710a93cff156

And here ist the FlexJS counterpart:

https://git1-us-west.apache.org/repos/asf?p=flex-falcon.git;a=commit;h=aea14be67db2b28b766d274d900ce076fdb8522b


Does it make sense to invest more time into this feature, or is this road a 
dead-end?


Chris

AW: Extending Maven to allow scope resolutions for other languages than Java

[Christofer Dutz]

Hi Guys,


thanks for that feedback ... I know my implementation was sort of ugly, but I 
tried to keep it as simple as possilbe as it seemed that the Eclipse Aether 
project didn't work on Aether for quite some time (Don't know if it's simply 
"finished" or if it's now maintained elsewhere). My option was a simple way to 
be able to extend this without having to change anything in Aether. But if 
there's a better, simpler, cleaner way ... I'd be more than happy to use that.


I have to admit that I'm still getting used to the internals of mavens DI 
mechanisms, so please forgive a mabe stupid question:

- I can see the DependencyGraphTransformer interface in Aether-API, can I 
already use this in Maven? I didn't quite understand if you said "it's coming" 
or "it's new but you can use it" ;-)

- If it's already there, how can I use it? Do I only have to provide an 
implementation of that? How do I tell Maven to use it (I'd really like to know 
if there is a way to inject custom versions of default services and have them 
used instead of the "Default" versions).

- If it's not there, what can I do to make it happen as soon as possible?


And Robert, I haven't forgotten about MPLUGIN-302 ... I'm still on it ... but 
for me it is very tightly coupled with this thing here ;-)


Chris




Von: Robert Scholte <rfscho...@apache.org>
Gesendet: Montag, 18. Juli 2016 20:39:58
An: Maven Developers List
Betreff: Re: Extending Maven to allow scope resolutions for other languages 
than Java

On Mon, 18 Jul 2016 15:54:24 +0200, Christian Schulte <c...@schulte.it>
wrote:

> Am 07/18/16 um 15:02 schrieb Christofer Dutz:
>> Hi,
>>
>>
>> Unfortuantely I wrote this down as a Jira ticket, but it seems it
>> wasn't created in the end so I'll post this via Email ;-)
>>
>>
>> I am currently working on clean support for Apache Flex build with
>> Maven. Prior to 3.3.1 non-java builds were sort of relying on a
>> scope-resolution bug that was fixed in newer version. Now non-default
>> scopes can no longer have transitive dependencies. In order to fix
>> this, I did a little refactoring of the scope resolution code in
>> MavenRepositorySystemUtils.newSession().
>>
>>
>> The idea is to wrap together the language-dependent parts of the scope
>> resolution and have these automatically injected into
>> DefaultRepositorySystemFactory. Per default there would only be one
>> instance (JavaLanguageSupport) available. But I could provide other
>> LanguageSupport implementations for other languages via Maven
>> extensions.
>>
>>
>> I implemented this as a POC. I didn't find my changes breaking anything
>> in the maven test-suite and I was able to add my FlexJsLanguageSupport
>> to maven and have it called for scope resolution requests.
>>
>>
>> I just pushed a commit to my maven fork:
>>
>> https://github.com/chrisdutz/maven/commit/cd205837540c3df74ad4a8eb8b6c710a93cff156
>>
>> And here ist the FlexJS counterpart:
>>
>> https://git1-us-west.apache.org/repos/asf?p=flex-falcon.git;a=commit;h=aea14be67db2b28b766d274d900ce076fdb8522b
>>
>>
>> Does it make sense to invest more time into this feature, or is this
>> road a dead-end?
>>
>
> Instead of adding that 'LanguageSupport' interface, I would go for
> injecting the 'DependencyGraphTransformer' to use directly. No need for
> a new interface. So that a customized 'ConflictResolver' can be injected
> you can setup the way you want. Makes things like your
> 'MultiLanguageScopeDeriver' part of your extension instead of Maven
> core. I think some kind of 'DependencyGraphTransformer' extension point
> will be provided in 3.5. Maybe there will be more than just one
> transformer for the various classpaths. We currently resolve the project
> artifacts once and then make Maven build the classpaths based on those
> artifacts. In 3.5 this may be enhanced to provide various artifact
> resolution strategies based on the classpath to build. So that
> 'MavenProject.getCompileClasspathElements' may provide different
> artifacts than 'MavenProject.getTestClasspathElements'. Nothing concrete
> yet.
>
> Regards,

I'd like to deprecate both MavenProject.getClasspathElements and
MavenProject.getTestClasspathElements. These are too tightly bound to
Java, whereas Maven should be language independent.
Yes, I thought of language extensions too, but with the new visions
regarding scopes it might not be necessary anymore.

Robert

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

Is there a reason extensions in ".mvn/extensions.xml" don't seem to support configuration?

[Christofer Dutz]

Hi,


I just noticed that the extensions.xml doesn't seem to support configuring an 
extension. Is this intentional because it would break things or is it simply 
that none needed or implemented that functionality yet?


Chris

Re: Is there a reason extensions in ".mvn/extensions.xml" don't seem to support configuration?

[Christofer Dutz]

Oh,

well I would have a use case for it. 
I am currently working on bringing more and more parts of Apache Flex from Ant 
to Maven. Here in a lot of places I have dependencies that are not yet 
available as Maven artifacts. While I managed to get in contact with quite some 
of the people maintaining those projects and to publish some of them at Maven 
Central, there still are quite some where my only solution is to have them 
downloaded via ANT and use scope=system for that, but I really hate that.

For the FlexSDK I created a maven extension which intercepts Mavens dependency 
resolution requests and if not being able to resolve, it manually produces 
maven artifacts. 

Now I thought it would be great to have a Maven extension that does this on a 
simpler basis, but on a more generic basis. I would like to define the 
extension in the extensions.xml file, but provide it with the configuration to 
produce the missing artifacts on the fly. I was thinking of reading a config 
file, located relative to the extensions.xml, but would prefer the 
configuration in the extensions.xml option.

I would be happy to be of assistance, but first I have to start and finish 
another thing I volunteered for first :-)

Chris





On 2016-07-05 18:48 (+0200), Igor Fedorenko <i...@ifedorenko.com> wrote: 
> The latter. My original prototype had configuration support (may still> 
> have the code somewhere, not sure) but we took it out because we didn't> 
> have immediate usecase and didn't want to commit to any specific format> 
> and api without clear understanding how it was going to be used..> 
> 
> -- > 
> Regards,> 
> Igor> 
> 
> On Tue, Jul 5, 2016, at 04:57 AM, Christofer Dutz wrote:> 
> > Hi,> 
> > > 
> > > 
> > I just noticed that the extensions.xml doesn't seem to support> 
> > configuring an extension. Is this intentional because it would break> 
> > things or is it simply that none needed or implemented that functionality> 
> > yet?> 
> > > 
> > > 
> > Chris> 
> 
> -> 
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org> 
> For additional commands, e-mail: dev-h...@maven.apache.org> 
> 
>  

-- 

Mit freundlichen Grüßen | Best regards
Christofer Dutz | Senior IT Consultant

codecentric AG | Kreuzmacher Straße 30 | 60486 Frankfurt | Deutschland

fax: +49 (0) 69.71492-682 | mobil: +49 (0) 1525.3057806 <> 

www.codecentric.de <http://www.codecentric.de/> | blog.codecentric.de 
<http://blog.codecentric.de/> | www.meettheexperts.de 
<http://www.meettheexperts.de/> | www.more4fi.de <http://www.more4fi.de/>


Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz

Diese E-Mail einschließlich evtl. beigefügter Dateien enthält vertrauliche 
und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige 
Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie 
bitte sofort den Absender und löschen Sie diese E-Mail und evtl. beigefügter 
Dateien umgehend. Das unerlaubte Kopieren, Nutzen oder Öffnen evtl. beigefügter 
Dateien sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

AW: Building Apache Maven

[Christofer Dutz]

Hi Rajiv,


I just had a look at my build. The version string comes from build.properties 
in maven-core.jar:/org/apache/maven/messages/build.properties


As the values are updated by the resources plugin during the build, I would 
imagine that they should be 3.4.0-SNAPSHOT or ${project.version} ... could you 
please check the following:

1. The maven-core.jar in the distribution is actually re-written and you are 
not using an old version?

2. The maven-core/target/classes/org/apache/maven/messages/build.properties 
contains the correct version?

3. The version in maven-core's pom is wrong (cause you're on the some other 
branch, not on head)?


Chris


Von: Rajiv Jain 
Gesendet: Donnerstag, 4. August 2016 22:42:08
An: Maven Developers List
Betreff: Re: Building Apache Maven

Hi

I wanted to chase up whether anybody can reply to the below e-mail?

Basically, I would like to produce a fresh build and test my changes on my 
fresh build.

I am using mvn - 
DdistributionTargetFolder=/Users/rajivpjs/tools/maven-test/apache-maven-3.4.0-SNAPSHOT
 clean package

>From this I used 
>/Users/rajivpjs/tools/maven-test/apache-test/apache-3.4.0-SNAPSHOT/bin/mvn -f 
>/path/to/pom.xml clean package -V

It displays version 3.3.9, instead of 3.4.0.

What am I doing wrong?

Thanks.

Regards,
Rajiv

> On 31 Jul 2016, at 08:40, Rajiv Jain  wrote:
>
> I forgot to mention pull request is 88.
>
> Sent from my iPhone
>
> On 31 Jul 2016, at 07:37, Rajiv Jain  > wrote:
>
>> Hi
>>
>> Based on a couple of previous e-mails and me doing one of the tasks, I 
>> identified that once I append -V during my fresh build I reliased I was 
>> still using the installed Maven.
>>
> mvn - 
> DdistributionTargetFolder=/Users/rajivpjs/tools/maven-test/apache-maven-3.4.0-SNAPSHOT
> clean package
>>
>> From this I used 
>> /Users/rajivpjs/tools/maven-test/apache-test/apache-3.4.0-SNAPSHOT/bin/mvn 
>> -f /path/to/pom.xml clean package -V
>>
>> Is this correct?
>>
>> Please could you review the pull request MNG-5910?
>>
>> Thanks.
>>
>> Regards,
>> Rajiv
>>
>>
>>
>> Sent from my iPhone
>>
>> On 23 Jul 2016, at 12:45, Karl Heinz Marbaise > > wrote:
>>
>>> Hi Rajiv,
>>>
>>> I have taken another look into your updated pull request...
>>>
>>> We usually don't use asterik imports...and furthermore you don't follow the 
>>> code style guide we have:
>>>
>>> http://maven.apache.org/developers/conventions/code.html 
>>> 
>>>
>>> If you runn a full build of what you have changed checkstyle should fail 
>>> here already...and give you a hint that the code style you have used is not 
>>> correct...
>>>
>>>
>>> Kind regards
>>> Karl Heinz
>>>
>>>
>>>
>>> On 7/22/16 7:50 PM, Rajiv Jain wrote:
 Hi

 Thanks for the quick reply. I will give that ago.

 Ignore me for the jre. My details are:

 mvn --version
 Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
 2015-11-10T16:41:47+00:00)
 Maven home: /Users/rajivpjs/Desktop/apache-maven-3.3.9/apache-maven-3.3.9

 For some reason I thought maven home is
 Users/rajivpsj/Desktop/apache-maven-3.3.9/apache-maven-3.3.9/jre

 Sorry for the confusion.

 Thanks once again.

 Just out of question, I raised a pull request a few days ago MNG-5910
 (https://github.com/apache/maven/pull/88 
 ). There was one review comment
 which I have fixed and I think this can be merged in. Could someone
 please look at and if fine then we can merge and close the pull request?

 Regards,
 Rajiv

> On 22 Jul 2016, at 18:33, Karl Heinz Marbaise  
> >> wrote:
>
> Hi,
>
>
> On 7/22/16 7:17 PM, Rajiv Jain wrote:
>> Hi
>>
>> I have recently started to make contributions to the Apache Maven
>> source code.
>>
>> I would like to know that if I wish to build a maven project using my
>> changes how would I do this?
>
>
> You can build Maven Core by using the following and let also the
> distribution being copied to a particular directory like this:
>
> mvn
> -DdistributionTargetFolder=/Users/kama/tools/maven-test/apache-maven-3.4.0-SNAPSHOT
> clean package
>
> I have a particular folder for the test version which I build from
> Maven core .
>
>
> Now if I like to use the build Maven version I simply use it directly:
>
> ~/tools/maven-test/apache-maven-3.4.0-SNAPSHOT/bin/mvn clean package
>
> So I use the build version here...
>
> Apart from that if you are making changes to Maven Core you should
> become familiar with the 

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

[Christofer Dutz]

AIR could be something Adobe might have a problem with ...


Chris


Von: Jörg Schaible 
Gesendet: Freitag, 5. August 2016 14:54:29
An: dev@maven.apache.org
Betreff: Re: [DISCUSSION] finishing Aether import: help find a new name

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

AW: [DISCUSS] Incorporating an ArchitectureId into the GAVCT of the repository

[Christofer Dutz]

We are having exactly the same problems in the Apache FlexJS project. Here we 
have libraries that compile to Flash (swc) or Libs that compile to JavaScript 
(js) or Libs that compile to both (jswc). Depending on the target 
"architecture" it would be great to have different dependency trees.


But I guess your problem could be solved (and has been for SWT deps) by using 
architecture-activated profiles and using classifiers for the architecture.


I know this doesn't work transitively though.


Chris


Von: Stephen Connolly 
Gesendet: Donnerstag, 1. September 2016 12:07:18
An: Maven Developers List
Betreff: [DISCUSS] Incorporating an ArchitectureId into the GAVCT of the 
repository

One of the things I feel is necessary to grow Maven in the modelVersion
5.0.0 world is to start taking account of architecture specific artifacts.

Currently, the Maven repository layout does not handle architecture
specific dependencies well.

So, for example:

Say I have a foo.jar that depends on a native library... bar.dll /
libbar.so / etc

Ideally we'd like to say that foo just depends on bar...

A consumer of foo that is running on, say my local machine, could then see
that I am running on os-x- x86_64 and because I am wanting to run tests...
it would look for bar with the architecture of `os-x-x86_64` to get the
native library for me

When I am building the installer for windows on my os-x machine (using say
.NET and the WiX toolchain) the corresponding (future does not exist yet)
maven plugin could request the win-x86 architecture of the dependency and
the rpm plugin could request the linux-ppc, linux-arm64, linux-x86 and
linux-x86_64 artifacts in order to produce the corresponding rpm
architecture artifacts

So when I think about this concept... I feel it is important that we find a
way to introduce the architectureId into the GACVT of the repository.

When we do this, to my mind, we need to be mindful that modelVersion 4.0.0
consumers would like to be able to consume these architecture specific
dependencies also... and the 4.0.0 GAV constraints will constrain the
possible solutions that we can pick if we value letting 4.0.0 consumers
access these architecture specific artifacts via the `default` layout we
currently employ for the maven repository.

So the first things first... our current `default` layout transforms the
GroupId:ArtifactId:Version:Classifier:Type into a repository URL of

`${groupId.replaceAll('.','/')}/${artifactId}/${version}/${artifactId}-${version}${classifier==null?'':'-'+classifier}.${type}`

If we want to add architectureId into that URL Path and still have that
resolvable by GAVCT at a modelVersion 4.0.0 coordinate, we are basically
left with stuffing the architectureId into one of the existing components...

Now when we think about an architecture specific artifact, the first thing
that comes to mind is that each architecture specific artifact most likely
has different dependencies... hopefully the .pdt file (that would be
deployed at the GAV without an architecture... modulo multi-machine builds)
would provide the architecture specific dependency trees so that
modelVersion 5.0.0 aware consumers would - just naturally - be aware of
those differences in dependencies

But - if we want to give the modelVersion 4.0.0 consumers our best effort -
we probably need to give each architectureId it's own modelVersion 4.0.0
pom.

In other words, I do not think we should try to munge the architectureId
into either classifier or type as both of those would force the
dependencies to be viewed as having the same dependencies in the
modelVersion 4.0.0 world

So that leaves us with groupId, artifactId and version...

I personally think version is a non-runner. In modelVersion 4.0.0 you can
only depend on one version of a dependency at a time... version ranges
would become completely and utterly unusable (never mind that they are
unusable now)... plus my gut tells me that it would be a total mess!

So that leaves groupId and artifactId... our choices basically boil down to

legacyGroupId == '${groupId}'; legacyArtifactId ==
'${architectureId}.${artifactId}'
legacyGroupId == '${groupId}'; legacyArtifactId ==
'${architectureId}-${artifactId}'
legacyGroupId == '${groupId}'; legacyArtifactId ==
'${artifactId}.${architectureId}'
legacyGroupId == '${groupId}'; legacyArtifactId ==
'${artifactId}-${architectureId}'
legacyGroupId == '${groupId}.${architectureId}'; legacyArtifactId ==
'${artifactId}'
legacyGroupId == '${groupId}.${artifactId}'; legacyArtifactId ==
'${architectureId}'

I personally think that the ones that place `architectureId` lexically
before `artifactId` are not "right"... the most important coordinate is the
groupId, the next most is the artifactId, then the architecture, then the
version, etc

So to my mind that leaves us with:

legacyGroupId == '${groupId}'; legacyArtifactId ==
'${artifactId}.${architectureId}'
legacyGroupId == 

AW: Making Maven extendable for non standard scopes

[Christofer Dutz]

Hi Robert,


Well I guess MPLUGIN-302 is about extending Maven to allow easy injection of 
dependencies of a given scope into a plugin. This would help use scopes in 
plugins. But I didn't interpret it as dealing with extending Maven to support 
other scopes in general. The way I understood it, it wouldn't help me get "rsl" 
scoped libraries as Maven doesn't know how to resolve these. If however I used 
scope "compile" I would get all compile scoped dependencies.


So for me MPLUGIN-302 is a very useful utility goodie, if Maven supported 
custom scopes.


I was thinking that from my point of view custom scope resolution would sort of 
be tightly coupled to the packaging of an artifact. So wouldn't the 
plugin-descriptor be a good place to declare such an extension?


I double checked and noticed that I am currently running my Builds with 
3.4-SNAPSHOT and I couldn't confirm the non-default scopes causing errors. So I 
guess this was a misunderstanding on my side.


Chris


Von: Robert Scholte <rfscho...@apache.org>
Gesendet: Dienstag, 13. September 2016 22:15:22
An: Maven Developers List
Betreff: Re: Making Maven extendable for non standard scopes

On Tue, 13 Sep 2016 09:34:38 +0200, Christofer Dutz
<christofer.d...@c-ware.de> wrote:

> Hi,
>
>
> I know there are several discussions underway in the context of pom 4.1
> and alike. The problem with this is however that it was impossible for
> me to follow those threads without putting my paid-work on hold ... a
> short summary of the current state would probably be a good Idea to get
> people back on board ;-)
>
>
> Last week I had a personal chat with Karl Heinz Marbaise at the
> Solutions.Hamburg conference.
>
> The thing is that in Maven a lot of things have been "fixed" recently. I
> put this in double quotes, because they have been fixed from a pure Java
> point of view, but have broken things for non Java projects. For example
> the Flex project had been relying on a "bug" in the resolver that used
> to treat the scopes of unknown types as "compile", for a while they have
> been treated as "runtime" (which strips out transitive dependencies).
> After that injecting project dependencies at runtime by a plugin seem to
> have been prohibited. Karl Heinz even mentioned non default scopes no
> longer producing warnings, but hard errors now (I can't confirm this as
> the new FlexJS Maven build is using these and I have been building this
> using Maven 3.4-SNAPSHOT for quite some time). If this is a future plan,
> this would break even more ... actually this would completely kill the
> ability to build anything with Flex.

Non-default scopes will cause errors? If that's true, I really need to
have a look at this. I would like to drop strict scopes and give plugins
the freedom to select their own scopes from the pom. Maybe the scopes must
be defined by the packaging plugin, that's something worth investigating.

You've already responded to MPLUGIN-302, what's the difference in this
story?

thanks,
Robert


>
>
> Now my suggestion was, as soon as Aether is fully integrated into
> Apache, to create some sort of extension point, in which projects could
> inject some sort of "ScopeProvider". So Maven would work with the normal
> scopes and break with any non-default ones, but using a plugin or a
> maven extension I could add additional scopes to Maven, where each new
> scope would probably need some sort of "ScopeResolver", which would then
> handle the resolving for that particular scope.
>
>
> I guess this would not only help the Flex project, but could help get a
> lot of the JS projects back, which seem to be moving to other build
> systems such as NPM, SBT, ... more and more.
>
>
> If there is anything I could do to help make this happen, please just
> guide me in the right direction and I'll get to it.
>
>
> Chris

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

Making Maven extendable for non standard scopes

[Christofer Dutz]

Hi,


I know there are several discussions underway in the context of pom 4.1 and 
alike. The problem with this is however that it was impossible for me to follow 
those threads without putting my paid-work on hold ... a short summary of the 
current state would probably be a good Idea to get people back on board ;-)


Last week I had a personal chat with Karl Heinz Marbaise at the 
Solutions.Hamburg conference.

The thing is that in Maven a lot of things have been "fixed" recently. I put 
this in double quotes, because they have been fixed from a pure Java point of 
view, but have broken things for non Java projects. For example the Flex 
project had been relying on a "bug" in the resolver that used to treat the 
scopes of unknown types as "compile", for a while they have been treated as 
"runtime" (which strips out transitive dependencies). After that injecting 
project dependencies at runtime by a plugin seem to have been prohibited. Karl 
Heinz even mentioned non default scopes no longer producing warnings, but hard 
errors now (I can't confirm this as the new FlexJS Maven build is using these 
and I have been building this using Maven 3.4-SNAPSHOT for quite some time). If 
this is a future plan, this would break even more ... actually this would 
completely kill the ability to build anything with Flex.


Now my suggestion was, as soon as Aether is fully integrated into Apache, to 
create some sort of extension point, in which projects could inject some sort 
of "ScopeProvider". So Maven would work with the normal scopes and break with 
any non-default ones, but using a plugin or a maven extension I could add 
additional scopes to Maven, where each new scope would probably need some sort 
of "ScopeResolver", which would then handle the resolving for that particular 
scope.


I guess this would not only help the Flex project, but could help get a lot of 
the JS projects back, which seem to be moving to other build systems such as 
NPM, SBT, ... more and more.


If there is anything I could do to help make this happen, please just guide me 
in the right direction and I'll get to it.


Chris

AW: [SUREFIRE] Jenkins job for junit5 branch

[Christofer Dutz]

Hi Guys ... I just setup such a build with the Pipeline Plugin for the Flex 
project ... is working nicely. I could help you with this, if you like?


Chris


Von: Tibor Digana 
Gesendet: Montag, 10. Oktober 2016 08:15:25
An: dev@maven.apache.org
Betreff: Re: [SUREFIRE] Jenkins job for junit5 branch

Excellent!

On Sun, Oct 9, 2016 at 2:16 PM, Benedikt Ritter [via Maven] <
ml-node+s40175n5882475...@n5.nabble.com> wrote:

> Hello,
>
> I've created a build job for the junit5 branch [1]. It's a copy of the
> maven-surefire job with the only difference that it does not publish build
> artifacts to the snapshots repository. It maybe possible to configure this
> more elegantly by using the Jenkins Pipeline Plugin, but I don't know how.
> I think this is good enough for a start.
>
> Regards,
> Benedikt
>
> [1] https://builds.apache.org/job/maven-surefire-junit5/
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/SUREFIRE-Jenkins-job-for-
> junit5-branch-tp5882475.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/Re-SUREFIRE-Jenkins-job-for-junit5-branch-tp5882626.html
Sent from the Maven Developers mailing list archive at Nabble.com.

AW: Some thoughts on Maven 5

[Christofer Dutz]

Hi Stephen,


My Username is "cdutz".


Chris


Von: Stephen Connolly <stephen.alan.conno...@gmail.com>
Gesendet: Sonntag, 16. Oktober 2016 13:49:39
An: Maven Developers List
Betreff: Re: Some thoughts on Maven 5

Let us know your cwiki username and we can grant permission to edit

On Sunday 16 October 2016, Christofer Dutz <christofer.d...@c-ware.de>
wrote:

> Hi guys,
>
>
> I just wanted to add one thing to the list:
>
> https://issues.apache.org/jira/browse/MNG-6107
>
> But I can't edit or comment on the page:
>
> https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
>
>
> Chris
>
> 
> Von: Stephen Connolly <stephen.alan.conno...@gmail.com <javascript:;>>
> Gesendet: Sonntag, 16. Oktober 2016 13:33:29
> An: Maven Developers List
> Betreff: Re: Some thoughts on Maven 5
>
> Adding a section to the wiki to help track this
>
> https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
>
> On 16 October 2016 at 04:12, Christian Schulte <c...@schulte.it
> <javascript:;>> wrote:
>
> > Am 10/16/16 um 02:03 schrieb Stephen Connolly:
> > >> On 16 Oct 2016, at 00:07, Christian Schulte <c...@schulte.it
> <javascript:;>> wrote:
> > >> Any thoughts about how to name that new build pom?
> > >
> > > project.mvn or pom.mvn
> > >
> > > But only if we move to a non-xml DSL
> > >
> > > If we are still XML then I say stick with pom.xml and sniff the
> > modelVersion
> >
> > +1
> >
> > Being able to build all Maven 2+ kinds of projects using Maven 5+ would
> > be cool. It's not a must have in my opinion. If this would degrade the
> > possibilities of Maven 5+, I'd say it's worth giving up on it.
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org <javascript:;>
> > For additional commands, e-mail: dev-h...@maven.apache.org
> <javascript:;>
> >
> >
>


--
Sent from my phone

AW: Some thoughts on Maven 5

[Christofer Dutz]

Hi guys,


I just wanted to add one thing to the list:

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

But I can't edit or comment on the page:

https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0


Chris


Von: Stephen Connolly 
Gesendet: Sonntag, 16. Oktober 2016 13:33:29
An: Maven Developers List
Betreff: Re: Some thoughts on Maven 5

Adding a section to the wiki to help track this

https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0

On 16 October 2016 at 04:12, Christian Schulte  wrote:

> Am 10/16/16 um 02:03 schrieb Stephen Connolly:
> >> On 16 Oct 2016, at 00:07, Christian Schulte  wrote:
> >> Any thoughts about how to name that new build pom?
> >
> > project.mvn or pom.mvn
> >
> > But only if we move to a non-xml DSL
> >
> > If we are still XML then I say stick with pom.xml and sniff the
> modelVersion
>
> +1
>
> Being able to build all Maven 2+ kinds of projects using Maven 5+ would
> be cool. It's not a must have in my opinion. If this would degrade the
> possibilities of Maven 5+, I'd say it's worth giving up on it.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [IMPORTANT CHANGE] building and publishing our website from Jenkins and Git instead of CMS

[Christofer Dutz]

Hi guys,

just stumbled over this thread ... sorry for not noticing it earlier.

As I did the same for several other projects here (Apache PLC4X probably being 
the most advanced site), I thought I might be able to help.

When updating to GIT, why not also switch to GitPubSub?

Also I just finished finetuning plc4x's Jenkinsfile ... perhaps it's worth 
having a look at. The important parts are:
- Build the site on any node able to do that (the "git-websites" labeled nodes 
shouldn't be used for the heavy testing ... we only have 1 or 2)
- Jenkins-Stash the generated site
- Unstash the site on a "git-websites" labeled node
- push the changes to the "asf-site" branch of the current projects repo
- check what's committed to the "asf-site" branch and reduce the changes to an 
absolute minimum (I removed most timestamp-stuff as the pub-sub-systems do tend 
to choke on large changes)

Some remarks from several months of working with this setup:
- As mentioned above: gitpubsub tends to choke on large changes. Whenever it 
choked no changes were published at all. Usually I had to beg Infra to re-sync 
the repos, a few weeks ago they added a "resync" to the self-service portal at 
https://selfserve.apache.org/ (The "synchronize git repositories" Button). 
Don't know if I begged so often, that they added the button to get rid of my 
begging ... but in the end now things work nicely. I did reduce the amount of 
choking by inspecting the commits done to the asf-site branch and refactored 
things to omit unnecessary timestamps and invisible things. 

And if you run into problems ... I'm glad to help ...

Chris

PLC4X's Jenkinsfile: 
https://github.com/apache/incubator-plc4x/blob/master/Jenkinsfile
PLC4X's Documentation on Website generation: 
http://plc4x.apache.org/developers/website.html




Am 11.05.18, 01:45 schrieb "Stephen Connolly" 
:

On Thu 10 May 2018 at 23:51, Hervé BOUTEMY  wrote:

> Le jeudi 10 mai 2018, 10:52:01 CEST Stephen Connolly a écrit :
> >
> 
https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven-site/j
> > ob/master/1/console looks good. @Hervé can you delete
> > https://builds.apache.org/view/M-R/view/Maven/job/maven-site/ if you are
> > happy with it?
> great job, even with multi-branch: I'll copy the Jenkinsfile to Doxia site
>
> How can we consult the local site build result? I don't see on master:
> would
> something appear in a branch?


Ok I am having a hard time parsing that request. Could you try to rephrase?


>
>
> >
> > On 10 May 2018 at 09:37, Stephen Connolly <
> stephen.alan.conno...@gmail.com>
> >
> > wrote:
> > > On 10 May 2018 at 07:25, Hervé BOUTEMY  wrote:
> > >> Le mercredi 9 mai 2018, 19:40:54 CEST Karl Heinz Marbaise a écrit :
> > >> > Hi,
> > >> >
> > >> >
> > >> > This means if you do a commit in the gitbox repository[1] the
> job[2] on
> > >> > our build server will start and deploy directly to production
> site[3]
> > >> > without the need to public via cms[4].
> > >>
> > >> yes, you get it
> > >>
> > >> > Great work...
> > >>
> > >> thank you
> > >>
> > >> > BTW: @Hervé can you explain what is meant to write the Jenkinsfile
> to
> > >> > make a mvn site-deploy ?
> > >>
> > >> currently, the Jenkins job that builds and deploy the website is
> manually
> > >> configured
> > >> If there was a Jenkinsfile in the git repo, the handcrafted Jenkins
> job
> > >> could
> > >> be replaced by the equivalent maven-box generated one
> > >> https://builds.apache.org/job/maven-box/
> > >>
> > >> My personal knowledge of Jenkinsfile and how to test it before
> committing
> > >> is
> > >> null, then we're staying for the moment with the handcrafted job
> > >>
> > >> Initially, I thought that only the Jenkinsfile would bring us the
> > >> immediate
> > >> rebuild on Git commit: but it seems the Git pubsub feature is
> available
> > >> also
> > >> on handcrafted job.
> > >
> > > Tsk Tsk did you think that little of me that I would implement pub-sub
> for
> > > multibranch and leave regular in the cold just to try and drive
> > > multibranch
> > > adoption :-(
> I don't know Jenkins sufficiently to know if Git pubsub is really a
> separate
> feature from Apache Hosted Git plugin: glad to see it works for any type
> of
> job
>
>
> > >
> > >> Then the only benefit we'll have is to remove the handmade
> > >> job: nice to have, but nothing critical...
> > >>
> > >> Regards,
> > >>
> > >> Hervé
> > >>
> > >> > Kind regards
> > >> > Karl Heinz Marbaise
> > >> >
> > >> >
> > >> >
> > >> > [1]: 

Re: [IMPORTANT CHANGE] building and publishing our website from Jenkins and Git instead of CMS

[Christofer Dutz]

Hi Hervé,

I could imagine that it could still work. As far as I understand all the 
gitpubsub and svnpubsub, what generally happens, is that the HTTPD server 
serving a projects website is just a directory. And the pubsubs just pull 
changes from a source to the static files directory of the projects HTTPD 
instance. Infra sets up jobs to pull from a VCS source and push to a directory. 
So it should be possible to mix at the target. If however the current setup is 
for multiple builds to push to a central website VCS, then I agree that with 
this setup it would be difficult, but eventually worth changing (Eventually 
even setting up a maven-components svn as target for all of this)

The reason for splitting up, was that in our case we wanted unit-test results, 
code-coverage etc. to be part of the site, this requires us to execute the 
unit- and integration-tests ... but executing the unit-test on the git-website 
node would needlessly block resources on these nodes. That's why with this 
setup we only use the ubuntu machines for publishing to nexus, the git-website 
nodes for updating the site asf-site branch and use our project VM build node 
for all other steps (We do low level network packet manipulation stuff there 
... that's why we run our tests on a dedicated machine).

Well I don't have a strong opinion on SVN or GIT as site-repo, I prefer GIT 
over SVN in general and I like having all things together. But besides that, I 
just thought I'd point out other options.

Chris




Am 11.05.18, 10:32 schrieb "Hervé BOUTEMY" <herve.bout...@free.fr>:

Hi Christofer,

Thanks for the sharing: the idea of building on any node, could be 
interesting 
in the future if we have performance issues with site commit-enabled nodes. 
Normally, these nodes are only used for site, which build is quite fast, so 
I'm not convinced there will be any issues in the near future. But at 
least, 
we already have a solution, to keep in mind.

On GitPubSub vs SvnPubSub:
We absolutely need SvnPubSub for components:
see https://maven.apache.org/developers/website/ and have a look at the 
content of components directory

Then I chose to let everything in svnpubsub: I could have done / from 
GitPubSub and /components from SvnPubSub, but the mix would IMHO have been 
more complex to understand. And I don't see much benefit to GitPubSub over 
SvnPubSub: the commit duration is a little bit faster, but not to a degree 
that I find useful enough to do the change.
Are there other benefits you see from GitPubSub over SvnPubSub?

Regards,

Hervé


On the idea of switching to GitPubSub

Le vendredi 11 mai 2018, 09:34:03 CEST Christofer Dutz a écrit :
> Hi guys,
> 
> just stumbled over this thread ... sorry for not noticing it earlier.
> 
> As I did the same for several other projects here (Apache PLC4X probably
> being the most advanced site), I thought I might be able to help.
 
> When updating to GIT, why not also switch to GitPubSub?
> 
> Also I just finished finetuning plc4x's Jenkinsfile ... perhaps it's worth
> having a look at. The important parts are:
 - Build the site on any node
> able to do that (the "git-websites" labeled nodes shouldn't be used for 
the
> heavy testing ... we only have 1 or 2) - Jenkins-Stash the generated site
> - Unstash the site on a "git-websites" labeled node
> - push the changes to the "asf-site" branch of the current projects repo
> - check what's committed to the "asf-site" branch and reduce the changes 
to
> an absolute minimum (I removed most timestamp-stuff as the pub-sub-systems
> do tend to choke on large changes)
 
> Some remarks from several months of working with this setup:
> - As mentioned above: gitpubsub tends to choke on large changes. Whenever 
it
> choked no changes were published at all. Usually I had to beg Infra to
> re-sync the repos, a few weeks ago they added a "resync" to the
> self-service portal at https://selfserve.apache.org/ (The "synchronize git
> repositories" Button). Don't know if I begged so often, that they added 
the
> button to get rid of my begging ... but in the end now things work nicely.
> I did reduce the amount of choking by inspecting the commits done to the
> asf-site branch and refactored things to omit unnecessary timestamps and
> invisible things. 
 
> And if you run into problems ... I'm glad to help ...
> 
> Chris
> 
> PLC4X's Jenkinsfile:
> https://github.com/apache/incubator-plc4x/blob/master/Jenkinsfile
 PLC4X's
> Documentation on Website generation:
> http://plc4x.apache.org/developers/website.html 
   

Doxia site renderer and current maven module context?

[Christofer Dutz]

Hi,

I am currently cleaning up the build of the Apache PLC4X project.
We are using Asciidoctor and a lot of its plugins to generate our site. We 
always had to sort of double-run asciidoctor as when running as site plugin the 
generated content is always generated into the root project.
Therefore we run the site plugin to generate the normal site content, but have 
it generate the images to a dummy directory of the root project. The in a 
second run, we have the normal asciidoctor-maven-plugin generate the normal 
content to a dummy directory of the current modules target and have it generate 
the images into the target/site directory. I now want to fix this.

The main problem is that the site configuration the asciidoctor doxia plugin 
uses is the one from the root of the project. The properties all also get 
resolved there. I tried using the lazy expansion suing @ instead of $, but all 
of that doesn’t work.

So my question now is: Is there a way to access the MavenProject of the current 
module an not of the root module?

Here’s the code of the thing:
https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/master/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java

I would really like to fix this correctly and not fork the plugin and patch in 
a hack that makes it work for my usecase. Right now I am using the Doxia Sink 
and getting some rudimentary information from that, but it’s not a pretty 
solution.

Chris

Re: Additional Maturity Metadata in artifacts (especially in the pom)?

[Christofer Dutz]

Hi Robert,

well how it's implemented in the end I don't really have any strong feelings. 
It just felt as if a 4.1.0 pom would make sense.
If in the end I am able to provide metadata, this metadata survives 
distribution through repository managers and we have
tooling to help utilize that information (enforcer-plugin-module to check a 
certain minimal maturity), then all is good.

I just noticed then working on the python stuff, that they had this and thought 
it would be great to have it in Maven too ;-)

Chris



Am 08.05.19, 23:18 schrieb "Robert Scholte" :

Remote repositories should always provide a model 4.0.0 pom, otherwise  
tools including all currently known Maven versions will not work. The  
first check is if the modelVersion is 4.0.0, otherwise Maven will simply  
stop working.

Since the pom on the system is copied/uploaded as-is, there's no way to do  
real improvements on the pom right now. This is quite hardened is Maven  
Core. So one of the things we are working on is implementing a way where  
the build-pom can be adjusted to a valid 4.0.0 before being published.  
Maven 3.6.x already contains a couple of preparations.

Once there's a separation, real improvements can be done. And then it  
makes sense to keep the the pom for builds, upload it as 4.0.0 and some  
new + improved format.

Robert


On Wed, 08 May 2019 22:48:38 +0200, Christofer Dutz  
 wrote:

> Ok ...
>
> And what's the:
> 4.0.0
> And the:
> xmlns="http://maven.apache.org/POM/4.0.0;
> About?
>
> One should think that a system like Nexus should be able to be extended  
> to support multiple POM Versions ...
> So as this metadata adds new features, wouldn't this simply be a  
> modelVersion=4.1.0?
>
> Chris
>
>
>
>
> Am 08.05.19, 20:38 schrieb "Robert Scholte" :
>
> On Wed, 08 May 2019 09:32:42 +0200, Christofer Dutz
>  wrote:
>> Well depending on how much metadata should be added ...
> >
> > Guess we already have a lot of stuff in the pom.xml which is  
> considered
> > metadata ... having some additional optional elements shouldn't  
> break
> > anything (I think)
>This part is actually very tricky. We've done it recently in order to
> control SCM path resolution, but it did break at several places, e.g.
> uploads to Centrals didn't work, because poms are validated against  
> the
> 4.0.0 XSD [1]. As you can see the 4.0.0 has been updated while  
> keeping the
> same version, not that elegant.
> If there is a place in the current version (e.g. existing String  
> element
> with new value) we could consider it, otherwise I would like to push  
> it
> forward.
>thanks,
> Robert
>[1] http://maven.apache.org/xsd/maven-4.0.0.xsd (look for attributes  
> with
> child.scm)
>> But adding some additional files exclusively used for metadata might
> > also be an option ... would this be alongside the pom and  
> artifacts or
> > inside the artifacts as static resources?
> > Cause having additional files alongside the pom and jar artifacts  
> for
> > example could require changing the tooling ... jar-embedded or
> > pom-embedded resources should work out of the box.
> >
> > Chris
> >
> > Am 06.05.19, 19:15 schrieb "Robert Scholte" :
> >
> > Assuming we need a new metadatafile in the future to  
> extend/enrich
> > the
> > current pom file, do you think it would fit in something like  
> a PDT
> > file[1]?
> >If so, please at a comment so we can take it into account when
> > working on
> > new specifications.
> >Robert
> >[1]
> >  
> 
https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema
> >On Mon, 06 May 2019 10:03:33 +0200, Christofer Dutz
> >  wrote:
> >> Hi all,
> > >
> > > I am currently working hard on adding support for other  
> languages
> > in the
> > > PLC4X maven build. While working on the python I noticed  
> that they
> > have
> > > some sort of maturity self-assessment metadata in their  
> artifacts

Re: Additional Maturity Metadata in artifacts (especially in the pom)?

[Christofer Dutz]

Ok ... 

And what's the:
4.0.0
And the:
xmlns="http://maven.apache.org/POM/4.0.0;
About?

One should think that a system like Nexus should be able to be extended to 
support multiple POM Versions ... 
So as this metadata adds new features, wouldn't this simply be a 
modelVersion=4.1.0?

Chris




Am 08.05.19, 20:38 schrieb "Robert Scholte" :

On Wed, 08 May 2019 09:32:42 +0200, Christofer Dutz  
 wrote:

> Well depending on how much metadata should be added ...
>
> Guess we already have a lot of stuff in the pom.xml which is considered  
> metadata ... having some additional optional elements shouldn't break  
> anything (I think)

This part is actually very tricky. We've done it recently in order to  
control SCM path resolution, but it did break at several places, e.g.  
uploads to Centrals didn't work, because poms are validated against the  
4.0.0 XSD [1]. As you can see the 4.0.0 has been updated while keeping the  
same version, not that elegant.
If there is a place in the current version (e.g. existing String element  
with new value) we could consider it, otherwise I would like to push it  
forward.

thanks,
Robert

[1] http://maven.apache.org/xsd/maven-4.0.0.xsd (look for attributes with  
child.scm)

> But adding some additional files exclusively used for metadata might  
> also be an option ... would this be alongside the pom and artifacts or  
> inside the artifacts as static resources?
> Cause having additional files alongside the pom and jar artifacts for  
> example could require changing the tooling ... jar-embedded or  
> pom-embedded resources should work out of the box.
>
> Chris
>
> Am 06.05.19, 19:15 schrieb "Robert Scholte" :
>
> Assuming we need a new metadatafile in the future to extend/enrich  
> the
> current pom file, do you think it would fit in something like a PDT
> file[1]?
>If so, please at a comment so we can take it into account when  
> working on
> new specifications.
>Robert
>[1]
> 
https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema
>On Mon, 06 May 2019 10:03:33 +0200, Christofer Dutz
>  wrote:
>> Hi all,
> >
> > I am currently working hard on adding support for other languages  
> in the
> > PLC4X maven build. While working on the python I noticed that they  
> have
> > some sort of maturity self-assessment metadata in their artifacts  
> and I
> > think that actually quite a good thing.
> >
> > Doing some research I couldn’t find any means to provide similar  
> data
> > for maven.
> >
> > In PLC4X we have a lot of modules. Some are older and mature, but  
> others
> > we’d like to mark as experimental.
> > It would be great if we could also provide enforcer rules to for  
> example
> > allow only mature modules or modules with a maturity scoring of at  
> least
> > X …
> >
> > I thing we could achieve something like this manually, by providing
> > metadata in form of resources in the jars and custom enforcer  
> modules,
> > but that would be an island solution only working in our domain. I  
> think
> > this could be beneficial to the entire Maven ecosystem to have  
> something
> > more generic in the system itself.
> >
> > Any thoughts & suggestions on this?
> >
> > Chris
>-
> 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: Additional Maturity Metadata in artifacts (especially in the pom)?

[Christofer Dutz]

Well depending on how much metadata should be added ... 

Guess we already have a lot of stuff in the pom.xml which is considered 
metadata ... having some additional optional elements shouldn't break anything 
(I think)
But adding some additional files exclusively used for metadata might also be an 
option ... would this be alongside the pom and artifacts or inside the 
artifacts as static resources?
Cause having additional files alongside the pom and jar artifacts for example 
could require changing the tooling ... jar-embedded or pom-embedded resources 
should work out of the box.

Chris

Am 06.05.19, 19:15 schrieb "Robert Scholte" :

Assuming we need a new metadatafile in the future to extend/enrich the  
current pom file, do you think it would fit in something like a PDT  
file[1]?

If so, please at a comment so we can take it into account when working on  
new specifications.

Robert

[1]  

https://cwiki.apache.org/confluence/display/MAVEN/Project+Dependency+Trees+schema

On Mon, 06 May 2019 10:03:33 +0200, Christofer Dutz  
 wrote:

> Hi all,
>
> I am currently working hard on adding support for other languages in the  
> PLC4X maven build. While working on the python I noticed that they have  
> some sort of maturity self-assessment metadata in their artifacts and I  
> think that actually quite a good thing.
>
> Doing some research I couldn’t find any means to provide similar data  
> for maven.
>
> In PLC4X we have a lot of modules. Some are older and mature, but others  
> we’d like to mark as experimental.
> It would be great if we could also provide enforcer rules to for example  
> allow only mature modules or modules with a maturity scoring of at least  
> X …
>
> I thing we could achieve something like this manually, by providing  
> metadata in form of resources in the jars and custom enforcer modules,  
> but that would be an island solution only working in our domain. I think  
> this could be beneficial to the entire Maven ecosystem to have something  
> more generic in the system itself.
>
> Any thoughts & suggestions on this?
>
> Chris

-
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

Additional Maturity Metadata in artifacts (especially in the pom)?

[Christofer Dutz]

Hi all,

I am currently working hard on adding support for other languages in the PLC4X 
maven build. While working on the python I noticed that they have some sort of 
maturity self-assessment metadata in their artifacts and I think that actually 
quite a good thing.

Doing some research I couldn’t find any means to provide similar data for maven.

In PLC4X we have a lot of modules. Some are older and mature, but others we’d 
like to mark as experimental.
It would be great if we could also provide enforcer rules to for example allow 
only mature modules or modules with a maturity scoring of at least X …

I thing we could achieve something like this manually, by providing metadata in 
form of resources in the jars and custom enforcer modules, but that would be an 
island solution only working in our domain. I think this could be beneficial to 
the entire Maven ecosystem to have something more generic in the system itself.

Any thoughts & suggestions on this?

Chris

AW: last review of Reproducible Builds proposal

[Christofer Dutz]

Hi all,

And I might want to add, that includes pom, jar, sources jar, javadoc, 
release-asembly and fat-jars ...

Currently applying these changes to other apache projects as an experiment.

So is anyone already working on the release plugin?

Chris

Von: Christofer Dutz 
Gesendet: Montag, 4. November 2019 18:58:10
An: Maven Developers List 
Betreff: Re: last review of Reproducible Builds proposal

Hi all,

so today I made sure the LastModified and the Creator username are omitted and 
now the Apache PLC4X build had a 100% reproducible build (at least on my one 
machine) ... will be checking this out on other machines.

Chris

Am 04.11.19, 10:12 schrieb "Christofer Dutz" :

Hi Andreas,

but the format of the timestamp is completely different ... doesn't that 
matter?
I was currently going for the option number 1 with removing the header.

In order to be 100% happy with this, I would prefer a setup where the 
normal mechanisms are used if no maven.build.outputTimestap is defined, but if 
it is (because a future version of the maven release plugin set it there) it 
uses that.

Will try out your suggestions as soon as I'm able to build again (I 
unfortunately installed that Mac OS update ... now things aren't working as 
they should be)

Chris



Am 04.11.19, 09:42 schrieb "Andreas Sewe" 
:

    Christofer Dutz wrote:
> Well I have a new candidate:
>
> maven-bundle-plugin
>
> Creates: Bnd-LastModified in the MANIFEST.MF
>
> Gotta find out a way to either suppress that entry (Would be great if 
it could consume the same property)


  
<_removeheaders>Bnd-LastModified
  


Alternatively


  
${maven.build.outputTimestap}
  

Re: last review of Reproducible Builds proposal

[Christofer Dutz]

Hi all,

so today I made sure the LastModified and the Creator username are omitted and 
now the Apache PLC4X build had a 100% reproducible build (at least on my one 
machine) ... will be checking this out on other machines.

Chris

Am 04.11.19, 10:12 schrieb "Christofer Dutz" :

Hi Andreas,

but the format of the timestamp is completely different ... doesn't that 
matter?
I was currently going for the option number 1 with removing the header.

In order to be 100% happy with this, I would prefer a setup where the 
normal mechanisms are used if no maven.build.outputTimestap is defined, but if 
it is (because a future version of the maven release plugin set it there) it 
uses that.

Will try out your suggestions as soon as I'm able to build again (I 
unfortunately installed that Mac OS update ... now things aren't working as 
they should be)

Chris



Am 04.11.19, 09:42 schrieb "Andreas Sewe" 
:
    
    Christofer Dutz wrote:
> Well I have a new candidate:
> 
> maven-bundle-plugin
>  
> Creates: Bnd-LastModified in the MANIFEST.MF
> 
> Gotta find out a way to either suppress that entry (Would be great if 
it could consume the same property)


  
<_removeheaders>Bnd-LastModified
  


Alternatively


  
${maven.build.outputTimestap}
  

Re: last review of Reproducible Builds proposal

[Christofer Dutz]

Hi Herve,

unfortunately I now have implemented some tooling to compare the stuff produced 
by the updated reproducible builds.
And it does show quite a number of non binary equal files.

Will investigate what's the difference.

Chris



Am 03.11.19, 11:08 schrieb "Hervé BOUTEMY" :

great feedback, thank you: this proves the initial set of only 3 plugins is 
a 
good basis.
For checking the many output artifacts from a build, future buildinfo file 
[1] 
should help a lot. I still have many usability concerns for Maven 
multi-module 
builds (starting with: should we generate only the root buildinfo or one 
buildinfo per Maven module?)
Let's keep the ball rolling: today, it's plugins release day!!!

Regards,

Hervé

[1] https://reproducible-builds.org/docs/jvm/

Le vendredi 1 novembre 2019, 13:34:32 CET Christofer Dutz a écrit :
> Hi,
> 
> so I just updated the versions of the 3 plugins and gave the Apache PLC4X
> build a little spin ...
> https://github.com/apache/plc4x/tree/feature/reproducible-builds
> 
> Did two executions of this: 
> mvn -U -P
> 
with-boost,with-java,with-dotnet,with-cpp,with-python,with-proxies,with-san
> dbox,with
> 
-DaltDeploymentRepository=snapshot-repo::default::file:./local-snapshots-di
> r clean deploy
 (but with a different second local repo location)
> 
> Then I used "diff" and "cmp" to compare individual files and it didn't 
show
> differences with the artifacts I chose ... 
 now I guess I'll have to whip
> up some little bash script to sort of compare the artifacts from one
> directory with the other (Unfortunately the SNAPSHOT timestamps are a
> little annoying :-/ 
> We do have some C++, C# and Python modules ... but I wouldn't expect the 
C++
> and C# to be reproducible.
 
> Chris
> 
> 
> Am 01.11.19, 12:04 schrieb "Hervé BOUTEMY" :
> 
> Le vendredi 1 novembre 2019, 09:40:40 CET Christofer Dutz a écrit :
> 
> > Hi Herve,
> > 
> > thanks for that will try it asap and report any findings back.
> > 
> > But good to know that there is a difference between JDK major 
versions
> > and
> > OSes ... so it would probably be best to stage releases on Linux 
with
> > an
> > OpenJDK of the minimum supported version?
> > Just thinking how to make it
> > possible to verify without having to buy Mac or Windows licenses ...
> > guess
> > on every machine you could whip up a Ubuntu VM for verification. 
Just
> > thinking about it ... perhaps it would be best to create a Docker
> > image for
 doing the reproducible stuff ...
> 
> just to be clear: the difference is on newline only, then Windows vs
> anything 
 else. You get the same result on Linux, MacOS, FreeBSD, or any
> other Unix. 
> And if I want to be complete, if you get a source tarball from 
Windows,
> 
 extract it to a Linux/MacOS/... box and build with "mvn -
> Dline.separator='\r\n'", in general, you get the same result as a 
build
> under 
 Windows: I tested multiple times, it worked, but we'll see if it
> works always or just "in general"
> 
> 
> > Are there any plans on creating a plugin to allow verification?
> > 
> > Sort of something like this:
> > "mvn package release:verify-reproduicble
> > -DstagingRepoUrl=a.b.c.de/repo/blahblahblah"
> > (Which doesn't deploy the
> > artifacts, but instead download them and do a binary comparison) 
> 
> yes, but for now it was completely another form: this is the 
"Buildinfo
> file" 
 proposal https://reproducible-builds.org/docs/jvm/
> that I stopped to work on 1 year ago given I had no chance to get the
> same 
 output: it's now a good time to restart working on it as next steps 
> 
> 
> > Also it could be great if the release-plugin could automatically set
> > the
> > property:
> > a) if it finds the "project.build.outputTimestamp" set to some
> > placeholder value b) if some switch tells it to prepare a
> > reproducible
> > build by using some sort of "switch" parameter 
> > Guess that would sort of close the loop to get the biggest benefit 
out
> > of
> > the reproducible builds.
> 
> +1
 

Re: last review of Reproducible Builds proposal

[Christofer Dutz]

Well I have a new candidate:

maven-bundle-plugin
 
Creates: Bnd-LastModified in the MANIFEST.MF

Gotta find out a way to either suppress that entry (Would be great if it could 
consume the same property)

Chris



Am 03.11.19, 20:25 schrieb "herve.bout...@free.fr" :

ok, Reproducible Builds are not so easy to get: each plugin that you use 
can cause an issue

I really recommend you diffoscope to investigate differences, it really 
helps a lot by easily giving you precise differences

Good luck for the investigations :)

Regards,

Hervé

- Mail original -
De: "Christofer Dutz" 
À: "Maven Developers List" 
Envoyé: Dimanche 3 Novembre 2019 20:16:42
Objet: Re: last review of Reproducible Builds proposal

Hi Herve,

unfortunately I now have implemented some tooling to compare the stuff 
produced by the updated reproducible builds.
And it does show quite a number of non binary equal files.

Will investigate what's the difference.

Chris



Am 03.11.19, 11:08 schrieb "Hervé BOUTEMY" :

great feedback, thank you: this proves the initial set of only 3 
plugins is a 
good basis.
For checking the many output artifacts from a build, future buildinfo 
file [1] 
should help a lot. I still have many usability concerns for Maven 
multi-module 
builds (starting with: should we generate only the root buildinfo or 
one 
buildinfo per Maven module?)
Let's keep the ball rolling: today, it's plugins release day!!!

Regards,

Hervé

[1] https://reproducible-builds.org/docs/jvm/

Le vendredi 1 novembre 2019, 13:34:32 CET Christofer Dutz a écrit :
> Hi,
> 
> so I just updated the versions of the 3 plugins and gave the Apache 
PLC4X
> build a little spin ...
> https://github.com/apache/plc4x/tree/feature/reproducible-builds
> 
> Did two executions of this: 
> mvn -U -P
> 
with-boost,with-java,with-dotnet,with-cpp,with-python,with-proxies,with-san
> dbox,with
> 
-DaltDeploymentRepository=snapshot-repo::default::file:./local-snapshots-di
> r clean deploy
 (but with a different second local repo location)
> 
> Then I used "diff" and "cmp" to compare individual files and it 
didn't show
> differences with the artifacts I chose ... 
 now I guess I'll have to whip
> up some little bash script to sort of compare the artifacts from one
> directory with the other (Unfortunately the SNAPSHOT timestamps are a
> little annoying :-/ 
> We do have some C++, C# and Python modules ... but I wouldn't expect 
the C++
> and C# to be reproducible.
 
> Chris
> 
    > 
    > Am 01.11.19, 12:04 schrieb "Hervé BOUTEMY" :
> 
> Le vendredi 1 novembre 2019, 09:40:40 CET Christofer Dutz a écrit 
:
> 
> > Hi Herve,
> > 
> > thanks for that will try it asap and report any findings back.
> > 
> > But good to know that there is a difference between JDK major 
versions
> > and
> > OSes ... so it would probably be best to stage releases on 
Linux with
> > an
> > OpenJDK of the minimum supported version?
> > Just thinking how to make it
> > possible to verify without having to buy Mac or Windows 
licenses ...
> > guess
> > on every machine you could whip up a Ubuntu VM for 
verification. Just
> > thinking about it ... perhaps it would be best to create a 
Docker
> > image for
 doing the reproducible stuff ...
> 
> just to be clear: the difference is on newline only, then Windows 
vs
> anything 
 else. You get the same result on Linux, MacOS, FreeBSD, or any
> other Unix. 
> And if I want to be complete, if you get a source tarball from 
Windows,
> 
 extract it to a Linux/MacOS/... box and build with "mvn -
> Dline.separator='\r\n'", in general, you get the same result as a 
build
> under 
 Windows: I tested multiple times, it worked, but we'll see if it
> works always or just "in general"
> 
> 
> > Are there any plans on creating a plugin to allow verification?
> > 
> > Sort of something like this:
> > "mvn package rel

Re: last review of Reproducible Builds proposal

[Christofer Dutz]

Hi all,

as I can see you're voting on releasing the reproducible build extended plugin 
versions.
Is there any documentation on how to use this new feature? 

I had a look at the confluence page, but that seemed like a brainstorming 
session.

I would love to add this to the PLC4X build asap. 
So I would like to test the release-candidates and vote too.

Chris



Am 16.10.19, 14:42 schrieb "Hervé BOUTEMY" :

Le mercredi 16 octobre 2019, 13:40:48 CEST Andreas Sewe a écrit :
> Emmanuel Bourg wrote:
> > Le 16/10/2019 à 08:35, Hervé BOUTEMY a écrit :
> >> last question: now that we seem to fully understand each other, does it
> >> mean that you don't need any more "seconds since the epoch" format
> >> support for the property?
> > 
> > If Maven supports the SOURCE_DATE_EPOCH environment variable I don't
> > think that's necessary, otherwise it would be nice to be able to invoke
> > 
> > Maven with:
> >mvn package -Dproject.build.outputTimestamp=$SOURCE_DATE_EPOCH
> > 
> > and this means supporting a timestamp formatted as seconds since the
> > epoch.
> 
> +1
> 
> The above would be a nice, simple way of bridging the gap between
> SOURCE_DATE_EPOCH and project.build.outputTimestamp.
told like that, ok, why not

> 
> If it is not too much trouble to implement the "\d+ -> seconds since
> epoch" heuristic, them I would love to see it included.
ok, I'll do and prepare the release

Regards,

Hervé

> 
> Best wishes,
> 
> Andreas





-
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: ASN.1 ECN

[Christofer Dutz]

Hi Mike,

But I definitely need to re-do the documentation.
http://plc4x.apache.org/developers/code-gen/protocol/mspec.html

I had started writing it before I did a big extension and refactoring …
I really hope I finally will get the chance to work on this again very soon.

Chris

Von: "Beckerle, Mike" 
Datum: Mittwoch, 30. Oktober 2019 um 17:32
An: Christofer Dutz , Julian Feinauer 
, "d...@plc4x.apache.org" 
Betreff: Re: ASN.1 ECN

Chris,

Thanks for this. Very useful. When I look at that  ASN.1 ECN definition I have 
the same reaction to it that I'm sure many non-XML people have to XML Schema 
and DFDL, which is there is much to learn, and so little of it seems relevant 
to the immediate problem. As soon as a description gets complex enough, it 
starts to lose its declarative value.

I think intellectually, we need to find a small, but representative piece of 
data and schema that has what you refer to as the "parsing semantics" of the 
message - the interesting calculations that are fundamental to really 
expressing *all* of the format information.  Then we need to express it in DFDL 
and in ASN.1 ECN best we can so we can have a side-by-side comparison that is 
really helpful.

What is the smallest, simplest format that you have seen that you think 
represents this? Do you have a description of it in MSpec as yet?

Thanks

Mike Beckerle

____
From: Christofer Dutz 
Sent: Saturday, October 26, 2019 9:42 AM
To: Julian Feinauer ; d...@plc4x.apache.org 

Cc: Beckerle, Mike 
Subject: Re: ASN.1 ECN


Hi Julian and others.



Yes I did have a look as ASN.1, however I had the impression that this only 
specifies the syntax of the packets themselves … it has no means to specify 
parsing semantics.

With MSpec we have the ability to also define these semantics … If we had used 
ASN.1 it would have generated models and parsers with every bit of information 
being included in the POJOs. When serializing we would have had to manually 
handle and prepare all the data.



For example the “implicit” fields … in MSpec we can say “headerLength is 
calculated by taking the total size in bytes, subtract the payload size in 
bytes and subract 2 more” with ASN.1 we would have had to do these caltulations 
ourselves.

Same with the discriminated types … here some data is implicity specified by 
the type itself (discriminators) … also the handling of optional fields and how 
to parse lists/arrays would have been challenging.



My evaluation might not have been 100% correct, but definitions like this did 
sort of scare me:

https://www.itu.int/ITU-T/formal-language/itu-t/x/x692/2008/Example3-EDM.html



Chris





Von: Julian Feinauer 
Datum: Samstag, 26. Oktober 2019 um 10:09
An: "d...@plc4x.apache.org" 
Cc: "Beckerle, Mike" , Christofer Dutz 

Betreff: Re: ASN.1 ECN



Hi Mike,



thanks fort he question which was also asked at ACEU, thus I’m bringing the 
discussion to the dev list.



Can you comment on that Chris? You did most of the evaluation.



Julian



Von: "Beckerle, Mike" 
Datum: Samstag, 26. Oktober 2019 um 06:32
An: Christofer Dutz , Julian Feinauer 

Betreff: ASN.1 ECN



For format description in PLC4X, did you consider ASN.1 Encoding Control 
Notation? This is an ISO standard. I have not used it, but it checks the boxes 
of being a standard, being a grammar + rich library of primitives annotated on 
it, etc.



If you did not consider it, or did and found it unsuitable, I'm interested in 
why.



...mike beckerle

Tresys/Daffodil

Re: last review of Reproducible Builds proposal

[Christofer Dutz]

Hi Herve,

thanks for that will try it asap and report any findings back.

But good to know that there is a difference between JDK major versions and OSes 
... so it would probably be best to stage releases on Linux with an OpenJDK of 
the minimum supported version?
Just thinking how to make it possible to verify without having to buy Mac or 
Windows licenses ... guess on every machine you could whip up a Ubuntu VM for 
verification.
Just thinking about it ... perhaps it would be best to create a Docker image 
for doing the reproducible stuff ...

Are there any plans on creating a plugin to allow verification?

Sort of something like this:
"mvn package release:verify-reproduicble 
-DstagingRepoUrl=a.b.c.de/repo/blahblahblah"
(Which doesn't deploy the artifacts, but instead download them and do a binary 
comparison)

Also it could be great if the release-plugin could automatically set the 
property:
a) if it finds the "project.build.outputTimestamp" set to some placeholder value
b) if some switch tells it to prepare a reproducible build by using some sort 
of "switch" parameter

Guess that would sort of close the loop to get the biggest benefit out of the 
reproducible builds.
I would be happy to help as I think this is one of the greatest new features.
(Ok ... perhaps besides the sound-output-extension I learned about yesterday 
;-) )


Chris


Am 01.11.19, 09:24 schrieb "Hervé BOUTEMY" :

    Le jeudi 31 octobre 2019, 17:26:52 CET Christofer Dutz a écrit :
> Hi all,
> 
> as I can see you're voting on releasing the reproducible build extended
> plugin versions.
 Is there any documentation on how to use this new
> feature?
> 
> I had a look at the confluence page, but that seemed like a brainstorming
> session.
ok, the Wiki page [1] started as a brainstorming session, was updated to a 
proposal (the "Output Archive Entries Timestamp" parapgraph).
And now I probably should order paragraph a little bit, and add a "Making 
your build reproducible" section for end uses to have a quick explanation.

I'll write the explanation here as a first try before working on the Wiki:

1. upgrade your plugins to reproducible version, particularly 
mpaven-source-plugin, maven-jar-plugin and maven-assembly-plugin to vesion 3.2.0
2. add project.build.outputTimestamp property with the timestamp value that 
will be used in zip/jar/tar archives:
  

2019-10-02T08:04:00Z
  

Notice:
- there is no Maven version prerequisite, everything happens at plugins 
level
- Reproducible Builds require to have no version ranges in dependencies, 
generally gives different result on Unixes vs Windows, and generally depend on 
the major version of JDK used to compile (see "Out of Scope" paragraph)

You have the basis configured, the output should be reproducible now.
If something is still not reproducible, use diffoscope to find the unstable 
output, find the plugin that generated this output and check if there is a 
reproducible version available: if not, please open an issue to help plugin 
maintainers improving Reproducible Builds support at every plugin level.

[1]  
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318


 
> I would love to add this to the PLC4X build asap.
I'd love to have feedback
Don't hesitate to ping me.
> 
> So I would like to test the release-candidates and vote too.
I would love to have many tester and votes :)

> 
> Chris
> 
> 
> 
> Am 16.10.19, 14:42 schrieb "Hervé BOUTEMY" :
> 
> Le mercredi 16 octobre 2019, 13:40:48 CEST Andreas Sewe a écrit :
> 
> > Emmanuel Bourg wrote:
> > 
> > > Le 16/10/2019 à 08:35, Hervé BOUTEMY a écrit :
> > > 
> > >> last question: now that we seem to fully understand each other,
> > >> does it
> > >> mean that you don't need any more "seconds since the epoch" 
format
> > >> support for the property?
> > > 
> > > 
> > > If Maven supports the SOURCE_DATE_EPOCH environment variable I
> > > don't
> > > think that's necessary, otherwise it would be nice to be able to
> > > invoke
> > > 
> > > Maven with:
> > > 
> > >mvn package -Dproject.build.outputTimestamp=$SOURCE_DATE_EPOCH
> > > 
> > > 
> > > and this means supporting a timestamp formatted as seconds since
> > > the
> > > epoch.
> > 
> > 
>

Re: Maven shade plugin: Duplicate entry in META-INF/service

[Christofer Dutz]

Hi Jan,

are you using any of the shade transformers? We had similar problems in the 
PLC4X project, but configuring:


  


Helped quite a bit.

Have a look here:
https://github.com/apache/plc4x/blob/develop/pom.xml#L1286

Hope this helps.

Chris

Am 03.12.19, 10:43 schrieb "Jan Lukavský" :

Hi Matt,

thanks for reaction. Is there a workaround around this? I think that the 
PR I propose is "safe" and might be considered as a hotfix before a 
proper solution is found? I don't know how is the release cycle of maven 
plugins defined, but if there is an upcoming release soon, this might help?

Jan

On 12/2/19 8:06 PM, Matt Foley wrote:
> Hi Jan,
> See also https://github.com/apache/maven-shade-plugin/pull/14 and 
MSHADE-259
>
> I stalled on it because it appears to be a lot of work to create unit 
tests for maven plugins — and there weren’t examples to follow in the shade 
plugin.
> That said, I’m not sure what I did is the right way to fix it.  I’ve seen 
emails go by that indicate the possibility of duplication in attachment lists 
affects several plugins, and the best way would be a global change in the 
underlying methods for “attachArtifact” that checks to see if the requested 
item is already there and not duplicate it if so (without error).
>
> Regards,
> —Matt
>
> On Nov 28, 2019, at 7:03 AM, Jan Lukavský  wrote:
>
> Hi Maven :),
>
> I encountered an exception in my build and I'm not sure if there is 
something wrong with how I structure tasks in my pom.xml, or there is a room 
for improvement of the shade plugin.
>
> The symptoms are as follows:
>
>   - mvn install works just fine
>
>   - mvn deploy fails on 'duplicate error: META-INF/service/' while 
shading test jar
>
> The reason for that seems that it includes the regular (not test-jar), 
and that one already includes the shaded service. When shading with the other 
dependencies, this fails. I managed to fix this locally with [1], but I'm not 
sure if this is a proper fix. I didn't fill any JIRA yet, because I wanted to 
check with you what the best solution should look like. I also don't know when 
or how this broke, but at least somewhat in early 2019 this worked. I probably 
changed the shade plugin to latest version later this year.
>
> Thanks for comments and suggestions!
>
> Jan
>
> [1] https://github.com/apache/maven-shade-plugin/pull/32
>
>
> -
> 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: last review of Reproducible Builds proposal

[Christofer Dutz]

Hi,

so I just updated the versions of the 3 plugins and gave the Apache PLC4X build 
a little spin ...
https://github.com/apache/plc4x/tree/feature/reproducible-builds

Did two executions of this: 
mvn -U -P 
with-boost,with-java,with-dotnet,with-cpp,with-python,with-proxies,with-sandbox,with
 -DaltDeploymentRepository=snapshot-repo::default::file:./local-snapshots-dir 
clean deploy
 (but with a different second local repo location)

Then I used "diff" and "cmp" to compare individual files and it didn't show 
differences with the artifacts I chose ... 
now I guess I'll have to whip up some little bash script to sort of compare the 
artifacts from one directory with the other (Unfortunately the SNAPSHOT 
timestamps are a little annoying :-/

We do have some C++, C# and Python modules ... but I wouldn't expect the C++ 
and C# to be reproducible.

Chris


Am 01.11.19, 12:04 schrieb "Hervé BOUTEMY" :

Le vendredi 1 novembre 2019, 09:40:40 CET Christofer Dutz a écrit :
> Hi Herve,
> 
> thanks for that will try it asap and report any findings back.
> 
> But good to know that there is a difference between JDK major versions and
> OSes ... so it would probably be best to stage releases on Linux with an
> OpenJDK of the minimum supported version?
> Just thinking how to make it
> possible to verify without having to buy Mac or Windows licenses ... guess
> on every machine you could whip up a Ubuntu VM for verification. Just
> thinking about it ... perhaps it would be best to create a Docker image 
for
> doing the reproducible stuff ... 
just to be clear: the difference is on newline only, then Windows vs 
anything 
else. You get the same result on Linux, MacOS, FreeBSD, or any other Unix.

And if I want to be complete, if you get a source tarball from Windows, 
extract it to a Linux/MacOS/... box and build with "mvn -
Dline.separator='\r\n'", in general, you get the same result as a build 
under 
Windows: I tested multiple times, it worked, but we'll see if it works 
always 
or just "in general"

> Are there any plans on creating a plugin to allow verification?
> 
> Sort of something like this:
> "mvn package release:verify-reproduicble
> -DstagingRepoUrl=a.b.c.de/repo/blahblahblah"
> (Which doesn't deploy the
> artifacts, but instead download them and do a binary comparison) 
yes, but for now it was completely another form: this is the "Buildinfo 
file" 
proposal https://reproducible-builds.org/docs/jvm/
that I stopped to work on 1 year ago given I had no chance to get the same 
output: it's now a good time to restart working on it as next steps


> Also it could be great if the release-plugin could automatically set the
> property:
> a) if it finds the "project.build.outputTimestamp" set to some
> placeholder value b) if some switch tells it to prepare a reproducible
> build by using some sort of "switch" parameter 
> Guess that would sort of close the loop to get the biggest benefit out of
> the reproducible builds.
+1
issue has been created https://issues.apache.org/jira/browse/MRELEASE-1029
But I didn't work on it yet, help welcome

> I would be happy to help as I think this is one
> of the greatest new features. (Ok ... perhaps besides the
> sound-output-extension I learned about yesterday ;-) ) 
+1
the current step is important, but it's only the beginning of the story 
from 
an effective usage perspective
    
Regards,

Hervé

> 
> Chris
> 
> 
> Am 01.11.19, 09:24 schrieb "Hervé BOUTEMY" :
> 
> Le jeudi 31 octobre 2019, 17:26:52 CET Christofer Dutz a écrit :
> 
> > Hi all,
> > 
> > as I can see you're voting on releasing the reproducible build
> > extended
> > plugin versions.
> 
>  Is there any documentation on how to use this new
> 
> > feature?
> > 
> > I had a look at the confluence page, but that seemed like a
> > brainstorming
> > session.
> 
> ok, the Wiki page [1] started as a brainstorming session, was updated 
to
> a proposal (the "Output Archive Entries Timestamp" parapgraph).
 And now I
> probably should order paragraph a little bit, and add a "Making your build
> reproducible" section for end uses to have a quick explanation. 
> I'll write the explanation here as a first try before working on the
> Wiki:
 
> 1. upgrade your plugins to reproducible v

Re: last review of Reproducible Builds proposal

[Christofer Dutz]

Hi Andreas,

but the format of the timestamp is completely different ... doesn't that matter?
I was currently going for the option number 1 with removing the header.

In order to be 100% happy with this, I would prefer a setup where the normal 
mechanisms are used if no maven.build.outputTimestap is defined, but if it is 
(because a future version of the maven release plugin set it there) it uses 
that.

Will try out your suggestions as soon as I'm able to build again (I 
unfortunately installed that Mac OS update ... now things aren't working as 
they should be)

Chris



Am 04.11.19, 09:42 schrieb "Andreas Sewe" :

Christofer Dutz wrote:
> Well I have a new candidate:
> 
> maven-bundle-plugin
>  
> Creates: Bnd-LastModified in the MANIFEST.MF
> 
> Gotta find out a way to either suppress that entry (Would be great if it 
could consume the same property)


  
<_removeheaders>Bnd-LastModified
  


Alternatively


  
${maven.build.outputTimestap}
  

Re: last review of Reproducible Builds proposal

[Christofer Dutz]

Just a small question. I have been following this thread with great interest.

I think this is going to be a big thing when it makes the changes available to 
the main maven system.

So as far as I understand the core part will be a fixed timestamp which will 
then be used throughout the build by multiple pluggins.

So if I provide the same timestamp the result should be binary identical.

Would it be possible to have this timestamp written/updated in the pom as part 
of the release:prepare step?

Sort of setting it to some constant (ie REPODUCEABLE_BUILD_TIMESTAMP) simply 
takes the current time but if there is a concrete value, it uses that instead?

Hope im not asking anything obvious. To me it looked as if the timestamp has to 
be manipulated manually.

Chris

Holen Sie sich Outlook für Android

From: Emmanuel Bourg 
Sent: Thursday, October 10, 2019 11:50:34 PM
To: dev@maven.apache.org 
Subject: Re: last review of Reproducible Builds proposal

Le 10/10/2019 à 19:28, Hervé BOUTEMY a écrit :

> the only little mis-interpretation is that it is a pure build information,
> then I don't see why this property would appear in a consumer POM

Thank you for the clarification, that makes perfectly sense. And I now
see the benefit of using a property that can be inherited. In a multi
modules project it's only necessary to define the timestamp once in the
root pom. Parent poms deployed to Maven Central will never include a
timestamp and there is no risk of affecting other projects deriving from
the pom.

Emmanuel Bourg

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

Re: last review of Reproducible Builds proposal

[Christofer Dutz]

Hi Enrico,

so I would definitely +1 to be able to do it this way ... 
I think reproducible builds are important for releases, but I am not that sure 
the same applies for the daily business in a project.
For being able to do releases it would be a huge improvement, if this is 
automatically handled the same way the versions are updated.

For the plc4x project I was even thinking of building some maven tooling to 
automatically verify the built archives with the ones staged in nexus for 
binary equality.

Chris

Am 11.10.19, 09:05 schrieb "Enrico Olivelli" :

Il ven 11 ott 2019, 08:31 Christofer Dutz  ha
scritto:

> Just a small question. I have been following this thread with great
> interest.
>
> I think this is going to be a big thing when it makes the changes
> available to the main maven system.
>
> So as far as I understand the core part will be a fixed timestamp which
> will then be used throughout the build by multiple pluggins.
>
> So if I provide the same timestamp the result should be binary identical.
>
> Would it be possible to have this timestamp written/updated in the pom as
> part of the release:prepare step?
>

Yep, this was one of my questions at the beginning of this thread.
I see value in this proposal

Enrico




> Sort of setting it to some constant (ie REPODUCEABLE_BUILD_TIMESTAMP)
> simply takes the current time but if there is a concrete value, it uses
> that instead?
>
> Hope im not asking anything obvious. To me it looked as if the timestamp
> has to be manipulated manually.
>
> Chris
>
> Holen Sie sich Outlook für Android<https://aka.ms/ghei36>
> 
> From: Emmanuel Bourg 
> Sent: Thursday, October 10, 2019 11:50:34 PM
> To: dev@maven.apache.org 
> Subject: Re: last review of Reproducible Builds proposal
>
> Le 10/10/2019 à 19:28, Hervé BOUTEMY a écrit :
>
> > the only little mis-interpretation is that it is a pure build
> information,
> > then I don't see why this property would appear in a consumer POM
>
> Thank you for the clarification, that makes perfectly sense. And I now
> see the benefit of using a property that can be inherited. In a multi
> modules project it's only necessary to define the timestamp once in the
> root pom. Parent poms deployed to Maven Central will never include a
> timestamp and there is no risk of affecting other projects deriving from
> the pom.
>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven Wrapper

[Christofer Dutz]

Hi Robert,

Well I am just worried, that in the end the situation in the incubator will not 
change.
There still might be -1 votes for not mentioning in the LICENSE that software 
from the ASF is included in a software package that is ASF anyway.
I do recall that it is considered nice to reference the project if the code is 
Apache Licensed and no NOTICE or LICENSE requires you to mention it.
But I also recall that it's not mandatory. 

So if the maven project would announce "you don't need to" this question could 
be off the table indefinitely ...

But IANALT so I would be interested in if this is actually correct.

Chris


Am 13.02.20, 19:33 schrieb "Robert Scholte" :

AFAIK these files are partly generated. Might be better to improve it there.

Robert
On 13-2-2020 07:29:46, Christofer Dutz  wrote:
Hi all,

would it also be possible for some sort of official statement that when 
copying the maven wrapper scripts (For Apache Projects), this doesn't 
explicitly have to be mentioned in the NOTICE or LICENSE file? I know that this 
could ease quite some +1/-1 discussions (especially on the incubator).

Chris

Am 13.02.20, 06:12 schrieb "James Gao" :

With maven wrapper, most maven project could be build out of box iff jdk is
installed, and the maven version used for build is locked by the project
owner. So in run time, each version of wrapper should be able to integrate
with as many as versions of maven. And so does the wrapper plugin, but
plugin is seldom used by by developers.

What the wrapper depends on are two very stable things:
a) how maven is distributed (a zip/tgz archive and its internal file
structures),
b) how maven is executed without wrapper (entry scripts, e.g. bin/mvn and
bin/mvn.cmd)

No matter how wrapper is distributed (via plugin or just copy from another
project), the deployed wrapper based on previous dependents, will deploy a
configurable version of maven to a personal location on the fly if needed,
then executed the previous deployed maven, but will not update the deployed
script itself.

So although wrapper will be released with maven core, it still better not
to lock the runtime version of maven.

On Thu, Feb 13, 2020 at 4:24 AM Robert Scholte wrote:

> well, with every release of Maven, some versions needed to be updated, see
> the commit logs.
> Also the release instructions show some relation with the Maven version.
>
> Based on that it looks like it should be part of core.
> I've understood doing a release of is a bit problematic due to some
> chicken-egg issue.
>
> However, I did start with the plugin and that one is now capable of
> recognizing the runtime version of Maven, not hardcoded.
>
> So it depends, I just haven't figured it out yet.
> On 12-2-2020 20:28:24, Enrico Olivelli wrote:
> Il Mer 12 Feb 2020, 19:58 Robert Scholte ha scritto:
>
> > Hi,
> >
> > This month we've finished the incubator process to move to code from the
> > maven wrapper to our project.
> >
>
> Cool
>
> >
> > Initially the idea was to move both the maven-wrapper and the
> > takari-maven-plugin (which contains a wrapper goal) to our codebase, but
> > due to conflicting licensing we only moved the maven-wrapper.
> >
> > Right now I've moved the code of the maven-wrapper to his own branch
> under
> > maven-studies.
> > From here we can work on it. I think it makes sense to make it a module
> of
> > Maven core, but that's still a decision we need to make.
> >
>
> Is it strictly dependent on a Maven version? I thought it was totally
> independent.
> Why not having a separate repository and release lifecycle?
>
> Enrico
>
>
> > For the maven-wrapper-plugin a new repository has been created. And I've
> > started with a clean branch, trying to set the base of this plugin.
> >
> > Both are open for further development, not just by me.
> >
> > So here are the 2 new git repositories:
> > https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git
> > (branch MWRAPPER-0_WIP)
> > https://gitbox.apache.org/repos/asf/maven-studies.git (branch
> > maven-wrapper)
> >
> >
> > Enjoy,
> > Robert
>



Т�ХF�?V�7V'67&��?R��?�â?FWb�V�7V'67&�?�?fV��???6�R��Фf�"??FF�F���?�?6���?�G2�?R��?�â?FWbֆV�??�?fV��???6�R��Р

Re: Maven Wrapper

[Christofer Dutz]

Hi all,

would it also be possible for some sort of official statement that when copying 
the maven wrapper scripts (For Apache Projects), this doesn't explicitly have 
to be mentioned in the NOTICE or LICENSE file? I know that this could ease 
quite some +1/-1 discussions (especially on the incubator).

Chris

Am 13.02.20, 06:12 schrieb "James Gao" :

With maven wrapper, most maven project could be build out of box iff jdk is
installed, and the maven version used for build is locked by the project
owner. So in run time, each version of wrapper should be able to integrate
with as many as versions of maven. And so does the wrapper plugin, but
plugin is seldom used by by developers.

What the wrapper depends on are two very stable things:
  a) how maven is distributed (a zip/tgz archive and its internal file
structures),
  b) how maven is executed without wrapper (entry scripts, e.g. bin/mvn and
bin/mvn.cmd)

No matter how wrapper is distributed (via plugin or just copy from another
project), the deployed wrapper based on previous dependents, will deploy a
configurable version of maven to a personal location on the fly if needed,
then executed the previous deployed maven, but will not update the deployed
script itself.

So although wrapper will be released with maven core, it still better not
to lock the runtime version of maven.

On Thu, Feb 13, 2020 at 4:24 AM Robert Scholte  wrote:

> well, with every release of Maven, some versions needed to be updated, see
> the commit logs.
> Also the release instructions show some relation with the Maven version.
>
> Based on that it looks like it should be part of core.
> I've understood doing a release of is a bit problematic due to some
> chicken-egg issue.
>
> However, I did start with the plugin and that one is now capable of
> recognizing the runtime version of Maven, not hardcoded.
>
> So it depends, I just haven't figured it out yet.
> On 12-2-2020 20:28:24, Enrico Olivelli  wrote:
> Il Mer 12 Feb 2020, 19:58 Robert Scholte ha scritto:
>
> > Hi,
> >
> > This month we've finished the incubator process to move to code from the
> > maven wrapper to our project.
> >
>
> Cool
>
> >
> > Initially the idea was to move both the maven-wrapper and the
> > takari-maven-plugin (which contains a wrapper goal) to our codebase, but
> > due to conflicting licensing we only moved the maven-wrapper.
> >
> > Right now I've moved the code of the maven-wrapper to his own branch
> under
> > maven-studies.
> > From here we can work on it. I think it makes sense to make it a module
> of
> > Maven core, but that's still a decision we need to make.
> >
>
> Is it strictly dependent on a Maven version? I thought it was totally
> independent.
> Why not having a separate repository and release lifecycle?
>
> Enrico
>
>
> > For the maven-wrapper-plugin a new repository has been created. And I've
> > started with a clean branch, trying to set the base of this plugin.
> >
> > Both are open for further development, not just by me.
> >
> > So here are the 2 new git repositories:
> > https://gitbox.apache.org/repos/asf/maven-wrapper-plugin.git
> > (branch MWRAPPER-0_WIP)
> > https://gitbox.apache.org/repos/asf/maven-studies.git (branch
> > maven-wrapper)
> >
> >
> > Enjoy,
> > Robert
>

Updating the apache parent to automatically clean before performing a release?

[Christofer Dutz]

Hi all,

I just wanted to suggest something I have noticed a lot of Apache projects were 
doing wrong. Especially when unexperienced RMs are doing the releases.

Several times now after doing a release, the RMs have uploaded the source 
bundles from “target” to the SVN. However they should have uploaded the 
“target/checkout/target”.
It is just too tempting to upload the versions left over from the 
release:prepare step as they too have the release version.

Usually this wouldn’t be a problem and I guess this has happened quite often in 
the past. The thing is with the adoption of the maven-wrapper we can 
unfortunately see when something’s going wrong.
In this case there is a difference. The source bundles from the prepare step 
then usually contain the ./mvn/maven-wrapper.jar … which is usually my 
indicator for instantly knowing what went wrong.
The version in the target/checkout simply couldn’t contain this file.

From the discussions with the reproducible builds I learned that you can define 
pre and post actions to the prepare and perform steps. So how about adding a 
pre-perform action that simply cleans the target directory?

I guess updating the default assembly to exclude the jar and class files in the 
“./mvn” directory could cure some symptoms, but people would still upload the 
wrong file.

I think this could prevent a lot of RCs being -1ed by Justin ;-)


Chris

Re: Updating the apache parent to automatically clean before performing a release?

[Christofer Dutz]

Hi Robert,

I would be more than happy to assist with making releases with maven easier for 
Apache projects ...
So if you give me a little update on what needs to be done, I might be able to 
spare some time and work on this.

But using the files from the prepare is the issue I'm trying to address ... the 
perform build is a clean checkout of the tagged version.
The clean checkout ensures the build is 100% clean ... things like packing in 
test-results, packing in maven-wrapper jars 
etc. only happens because the source distribution is not built in a clean 
environment.

I would love if it was possible to extend questions the release-prepare plugin 
asks for ... so if it would ask for a RC number, 
we could add a call to the scm:checkin goal in the deploy phase of a 
release-perform build as part of the "apache-release" profile.
The only piece of information that’s missing, would be the release-candidate 
number.


Chris



Am 05.01.20, 14:07 schrieb "Robert Scholte" :

ASF deserves a customized release strategy, which is now possible with 
MRELEASE-956
My idea is that during "prepare" the plugin should upload several files to 
the ASF dist folder besides the tagging.
During "perform" it should use these files instead of the tag in SCM 
(because these files are the official releases, not the tag).

Just waiting for someone to pick it up.

thanks,
Robert


[1] https://jira.apache.org/jira/browse/MRELEASE-956
    On 5-1-2020 11:28:22, Christofer Dutz  wrote:
Hi all,

I just wanted to suggest something I have noticed a lot of Apache projects 
were doing wrong. Especially when unexperienced RMs are doing the releases.

Several times now after doing a release, the RMs have uploaded the source 
bundles from “target” to the SVN. However they should have uploaded the 
“target/checkout/target”.
It is just too tempting to upload the versions left over from the 
release:prepare step as they too have the release version.

Usually this wouldn’t be a problem and I guess this has happened quite 
often in the past. The thing is with the adoption of the maven-wrapper we can 
unfortunately see when something’s going wrong.
In this case there is a difference. The source bundles from the prepare 
step then usually contain the ./mvn/maven-wrapper.jar … which is usually my 
indicator for instantly knowing what went wrong.
The version in the target/checkout simply couldn’t contain this file.

From the discussions with the reproducible builds I learned that you can 
define pre and post actions to the prepare and perform steps. So how about 
adding a pre-perform action that simply cleans the target directory?

I guess updating the default assembly to exclude the jar and class files in 
the “./mvn” directory could cure some symptoms, but people would still upload 
the wrong file.

I think this could prevent a lot of RCs being -1ed by Justin ;-)


Chris

Re: Updating the apache parent to automatically clean before performing a release?

[Christofer Dutz]

Hi Herve,

he'll only get the same content if everything is done right ... unfortunately 
for example the IoTDB project had to re-do quite a number of RCs as they were 
still not 100% doing things the maven way.
In PLC4X we just had to cancel a release of a sub-project due to the 
maven-wrapper.jar being packaged in.

There were tests writing things outside the target directory, which they were 
manually excluding. The maven-wrapper.jar keeps on being packaged by the 
default apache source assembly.
Sometimes GIT excluded temp files are packaged. Only by running the release in 
the target/checkout directory you can be 100% sure it's a clean structure 
you're packaging.

I know that most problems are due to people not doing things the official 
"maven way" (TM) ... but I have to admit being involved in a lot of projects,
if we could ensure some of the common pitfalls don't have such a severe impact, 
we could help a lot of projects.


Chris



Am 05.01.20, 18:33 schrieb "Hervé BOUTEMY" :

notice that with Reproducible Builds being active by default, the source 
archive is reproducible and RM will get the same content in both locations

There is only the .asc signature file that contains a different timestamp

I'm just launching the long overdue Apache Parent 22 vote that will enable 
Reproducible Builds by default, we'll see if a new release will be ready 
soon

Regards,

Hervé

Le dimanche 5 janvier 2020, 14:41:37 CET Christofer Dutz a écrit :
> Hi Robert,
> 
> I would be more than happy to assist with making releases with maven 
easier
> for Apache projects ...
 So if you give me a little update on what needs to
> be done, I might be able to spare some time and work on this. 
> But using the files from the prepare is the issue I'm trying to address 
...
> the perform build is a clean checkout of the tagged version.
 The clean
> checkout ensures the build is 100% clean ... things like packing in
> test-results, packing in maven-wrapper jars etc. only happens because the
> source distribution is not built in a clean environment. 
> I would love if it was possible to extend questions the release-prepare
> plugin asks for ... so if it would ask for a RC number, 
 we could add a
> call to the scm:checkin goal in the deploy phase of a release-perform 
build
> as part of the "apache-release" profile. The only piece of information
> that’s missing, would be the release-candidate number. 
> 
> Chris
> 
> 
> 
> Am 05.01.20, 14:07 schrieb "Robert Scholte" :
> 
> ASF deserves a customized release strategy, which is now possible with
> MRELEASE-956
 My idea is that during "prepare" the plugin should upload
> several files to the ASF dist folder besides the tagging. During "perform"
> it should use these files instead of the tag in SCM (because these files
> are the official releases, not the tag). 
> Just waiting for someone to pick it up.
> 
> thanks,
> Robert
> 
> 
> [1] https://jira.apache.org/jira/browse/MRELEASE-956
> On 5-1-2020 11:28:22, Christofer Dutz 
> wrote:
 Hi all,
> 
> I just wanted to suggest something I have noticed a lot of Apache
> projects were doing wrong. Especially when unexperienced RMs are doing the
> releases.
 
> Several times now after doing a release, the RMs have uploaded the
> source bundles from “target” to the SVN. However they should have uploaded
> the “target/checkout/target”.
 It is just too tempting to upload the
> versions left over from the release:prepare step as they too have the
> release version. 
> Usually this wouldn’t be a problem and I guess this has happened quite
> often in the past. The thing is with the adoption of the maven-wrapper we
> can unfortunately see when something’s going wrong.
 In this case there is
> a difference. The source bundles from the prepare step then usually 
contain
> the ./mvn/maven-wrapper.jar … which is usually my indicator for instantly
> knowing what went wrong. The version in the target/checkout simply 
couldn’t
> contain this file. 
> From the discussions with the reproducible builds I learned that you 
can
> define pre and post actions to the prepare and perform steps. So how about
> adding a pre-perform action that simply cleans the target directory?
 
> I guess updating the default assembly to exclude the jar and class 
files

Re: Your project website

[Christofer Dutz]

Hi all,

In the plc4x project we're building the project website during the build of the 
develop branch. It's all a maven site with custom skin, and auto deployed via 
git-pubsub. All on Aspache infra.

Works nicely.

Chris



Von: Manfred Moser 
Gesendet: Donnerstag, 20. August 2020 06:23
An: infrastruct...@apache.org ; dev@maven.apache.org 

Cc: dev@maven.apache.org 
Betreff: Re: Your project website

Also ... from a technical standpoint the Maven site is just a bunch of static 
html files and I think some server side includes. We might have to fix those to 
be different depending on whatever we migrate to .. with that in mind..

What are our options within the Apache infrastructure or outside?

Manfred

Olivier Lamy wrote on 2020-08-19 18:33 (GMT -07:00):

> Hi Andrew & Infra
> We (maven-dev) wonder what does it mean with using Apache CMS?
> As far as we can see, we only generate content and commit it to a svn
> directory.
> Maybe not for the root part of the website (sources are here
> https://gitbox.apache.org/repos/asf?p=maven-site.git) which is triggered in
> buildbot?
> Please let us know if it's part you refer as our usage of Apache CMS
> Thanks
> Olivier
>
>
> On Tue, 18 Aug 2020 at 9:54 pm, Andrew Wetmore  wrote:
>
>> Hi:
>>
>> I wrote to you two weeks ago about your project website, but have not seen
>> a response. Whom should I contact directly? I am trying to see whether your
>> project still uses the Apache CMS and, if so, what your plans are to
>> migrate off it.
>>
>> Thanks in advance for your help.
>>
>> Andrew
>>
>> On Wed, Aug 5, 2020 at 9:35 AM Andrew Wetmore  wrote:
>>
>>> Hi:
>>>
>>> I am part of the Infrastructure team, and am writing to ask whether your
>>> project is still using the Apache CMS for your project website. As you
>>> know, the CMS is reaching end-of-life, and we need projects to move their
>>> websites onto a different option within the next few weeks.
>>>
>>> There are several alternatives available, including those listed on this
>>> page [1] on managing project websites. Infra is assembling a Wiki page [2]
>>> on migrating a website from the CMS, and is looking forward to helping
>>> projects with this transition.
>>>
>>> Please let me know whether your site is still on the Apache CMS and, if
>>> so, who will be the project point-of-contact with Infra for the migration.
>>>
>>> Thank you!
>>>
>>>
>>>
>>>
>>> [1] https://infra.apache.org/project-site.html
>>>
>>> [2]
>>> https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS
>>>
>>>
>>> --
>>> Andrew Wetmore
>>> Technical Writer-Editor
>>> Infra
>>> *Apache Software Foundation*
>>> andr...@apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 
>>> Virus-free. www.avast.com
>>> 
>>>
>>>
>>>
>>>
>>> <#m_7218770601526193449_m_2382004626366778703_m_1277653308293069744_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>>
>>>
>>
>> --
>> Andrew Wetmore
>> Technical Writer-Editor
>> Infra
>> *Apache Software Foundation*
>> andr...@apache.org
>>
>>
>>
>

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

Re: Maven builds out of control

[Christofer Dutz]

Hi all,

Well you could probably self-limit your builds.

I know that when using Jenkinsfiles you can define tags for nodes the build 
runs on.
So you could probably limit these to a hand full of "H??" nodes and it should 
not use up all of the resources.

Chris

Am 17.08.20, 10:23 schrieb "Arnaud Héritier" :

If we are consuming too much resources couldn't we have a dedicated Jenkins
controller and/or limit our agents capacities to be the one ones to be
impacted by these problems instead of all the users or this Jenkins
controller ?
Beam, Cassandra, CouchDB and few more have a dedicated controller :
https://jenkins-ccos.apache.org/job/masters/
What are the rules to have a dedicated one ?

On Mon, Aug 17, 2020 at 10:02 AM Michael Osipov  wrote:

> Am 2020-08-17 um 09:55 schrieb Olivier Lamy:
> > Furthermore, we need to clean up unused branches.
> > What about removing branches older than 1yo?
> > Then older than 6months?
>
> I consider branches which have been merged obsolete, but there is no
> hard rule that an unmerged branch is obsolete. It may prepresent an
> unfished state or something which was not agreed on. Dropping work does
> not feel right. It needs to be decided on a case-by-case approach.
> I have done this recently for Wagon and Resolver.
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Arnaud Héritier
Twitter/Skype : aheritier

Re: [RESULT] [VOTE] Release Apache Maven Wrapper Plugin version 3.0.1

[Christofer Dutz]

Well doesn't have to be compatible as long as it does what it's supposed to.

Was just asking as I wrote the Downloader to enable Apache projects to use the 
maven wrapper (No checked in binaries)
Unfortunately we always were required to maintain the NOTICE reference that the 
scripts and the java file were third party stuff.
Just looking forward to replacing this all with the new source-distribution and 
to no longer have discussions on what has to be in the NOTICE file.

Chris



Am 03.06.20, 18:56 schrieb "Robert Scholte" :

Starting with Maven 3.7.0 there will be 3 wrapper distributions, 
org.apache.maven:apache-maven-wrapper
and with the following classifiers:
script: mvnw, mvnw.cmd, mvnwDebug, mvnwDebug.cmd, 
.mvn/wrapper/maven-wrapper.properties
bin: like script, but also .mvn/wrapper/maven-wrapper.jar

source: like script, but also .mvn/wrapper/MavenWrapperDownloader.java

I am not aware of any NOTICE file.
I expect that it can be a replacement, but for me this wrapper code is is a 
new brand feature in Maven, so there hasn't been any attempt to be backwards 
compatible with the takari code.

thanks,
Robert

On 3-6-2020 09:11:53, Christofer Dutz  wrote:
Congrats on this ...

As the rest is usually just dropping the mwnw scripts, the config file and 
my downloader.java ...
is there an apache package we can now just drop in to replace the old and 
get rid of the Notice stuff?

Chris


Am 02.06.20, 22:36 schrieb "Robert Scholte" :

Hi,

The vote has passed with the following result:

+1 : Robert Scholte, Romain Manni-Bucau, Olivier Lamy, Hervé BOUTEMY, 
Maarten Mulders

PMC quorum: reached

I will promote the artifacts to the central repo.

On 30-5-2020 11:17:43, Robert Scholte wrote:
Hi,

I'd like to do a bootstrap release of the maven-wrapper-plugin, in order to 
configure it in the next maven-core.

We solved 1 issue:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12348346=Text

There are no issues in JIRA:

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

Staging repo:
https://repository.apache.org/service/local/repositories/maven-1584/

https://repository.apache.org/service/local/repositories/maven-1584/content/org/apache/maven/plugins/maven-wrapper-plugin/3.0.1/maven-wrapper-plugin-3.0.1-source-release.zip

(note: there are some issues with https://repository.apache.org/ : you 
cannot browse through the content, but you can download the zip )

Source release checksum(s):
maven-wrapper-plugin-3.0.1-source-release.zip sha512: 
04084e8806af4507996ce7d9caafc1a9ff2c9e278ba1c0f41552edb6516d75f1685177130c76c04c262376437d96be3083c2b46309c482ab07b74785c35dafcb

Staging site:
https://maven.apache.org/plugins-archives/maven-wrapper-plugin-LATEST/

Guide to testing staged releases:
As this is a special bootstrapping release, the following instructions are 
a proper way of testing:

- clone/download+unpack current master branch of Apache Maven core ( 
https://github.com/apache/maven ) (this will make all apache-maven-wrapper 
distributions available in your local repository)
- run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo install'
- download+unpack sources from maven-wrapper-plugin (see above)
- run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo install'
- go to the root of any Maven project
- run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo wrapper:wrapper 
-DwrapperVersion=3.7.0-SNAPSHOT' with optional extra arguments

NOTE: be aware of the difference between maven-wrapper and the 
maven-wrapper-plugin.
The maven-wrapper-plugin only downloads and unpacks the maven wrapper 
scripts.
The content of the maven-wrapper scripts are not part of the plugin, hence 
not part of this release.
Adjustments to that content belong to Maven core

https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

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


?B�CB�?�?[��X��ܚX�K??K[XZ[?�??]�][��X��ܚX�P?X]�[��\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[�?�??K[XZ[?�??]�Z?[???X]�[��\?X�?K�ܙ�B�

Re: [RESULT] [VOTE] Release Apache Maven Wrapper Plugin version 3.0.1

[Christofer Dutz]

Congrats on this ... 

As the rest is usually just dropping the mwnw scripts, the config file and my 
downloader.java ... 
is there an apache package we can now just drop in to replace the old and get 
rid of the Notice stuff?

Chris


Am 02.06.20, 22:36 schrieb "Robert Scholte" :

Hi,

The vote has passed with the following result:

+1 : Robert Scholte, Romain Manni-Bucau, Olivier Lamy, Hervé BOUTEMY, 
Maarten Mulders

PMC quorum: reached

I will promote the artifacts to the central repo.

On 30-5-2020 11:17:43, Robert Scholte  wrote:
Hi,

I'd like to do a bootstrap release of the maven-wrapper-plugin, in order to 
configure it in the next maven-core. 

We solved 1 issue:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12348346=Text

There are no issues in JIRA:

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

Staging repo:
https://repository.apache.org/service/local/repositories/maven-1584/

https://repository.apache.org/service/local/repositories/maven-1584/content/org/apache/maven/plugins/maven-wrapper-plugin/3.0.1/maven-wrapper-plugin-3.0.1-source-release.zip

(note: there are some issues with https://repository.apache.org/ : you 
cannot browse through the content, but you can download the zip )

Source release checksum(s):
maven-wrapper-plugin-3.0.1-source-release.zip sha512: 
04084e8806af4507996ce7d9caafc1a9ff2c9e278ba1c0f41552edb6516d75f1685177130c76c04c262376437d96be3083c2b46309c482ab07b74785c35dafcb

Staging site:
https://maven.apache.org/plugins-archives/maven-wrapper-plugin-LATEST/

Guide to testing staged releases:
As this is a special bootstrapping release, the following instructions are 
a proper way of testing:

- clone/download+unpack current master branch of Apache Maven core ( 
https://github.com/apache/maven ) (this will make all apache-maven-wrapper 
distributions available in your local repository)
- run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo install'
- download+unpack sources from maven-wrapper-plugin (see above)
- run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo install'
- go to the root of any Maven project
- run 'mvn -Dmaven.repo.local=/temp/wrapper-itrepo wrapper:wrapper 
-DwrapperVersion=3.7.0-SNAPSHOT' with optional extra arguments

NOTE: be aware of the difference between maven-wrapper and the 
maven-wrapper-plugin.
The maven-wrapper-plugin only downloads and unpacks the maven wrapper 
scripts.
The content of the maven-wrapper scripts are not part of the plugin, hence 
not part of this release.
Adjustments to that content belong to Maven core

https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

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

AW: Request for Enhancement: Dependency Overrides

[Christofer Dutz]

Coming a bit late to the party ... I think this is something I had been 
requesting every 1-2 years for some time.
As during my time as a consultant migrations to Maven I keept running into this 
problem. Here I usually had the task of streamlining the dependency usage of 
many teams so their end-products worked together nicely. 

Here I had a lot of problems like: Someone using a fat-jar instead of a normal 
jar. Someone using wrong coordinates (third party release of something and not 
using the official one). DepgendencyManagement exclusions helped getting rid of 
these, but we needed to find out which modules relied on them and had to add 
dependencies to each module manually. In the worst case I had to communicate 
with the team-leads of 200 development teams for them to update their poms (And 
I guess everyone working in banks knows: One does not simply commit to a repo 
that's not your team's repo). I think I asked for dependencyManagement to add 
an "inclusions" element to the "exclusions" ... perhaps that would be something 
worth considering?

But all in all ... I'm totally +1 for a feature like that.

Chris

-Ursprüngliche Nachricht-
Von: Romain Manni-Bucau  
Gesendet: Sonntag, 15. August 2021 08:36
An: Maven Developers List 
Betreff: Re: Request for Enhancement: Dependency Overrides

Le sam. 14 août 2021 à 22:21, Enno Thieleke  a 
écrit :

> Ok, I feel like we're turning in circles here.
>
> If the feature I'm proposing exists already (without excludes and 
> without the need for extra POMs and BOMs, i.e. the common solution), 
> please post a link to the docs. If it doesn't exist and people ask for 
> it [1] (and have been for years), then I don't see why you'd want to reject 
> it.
>

It requires excludes, as your proposal does (since to override a jar you need 
to list the excluded one, this is literally an exclude even if you name 
differently the tag).
Since it can be done globally in the dep mgt it is exactly what you request 
except you control your dependencies whereas you want to apply rules without 
knowing if they are useful so it means you will need to add a 
dependency:check-overrides mojo just for that purpose and users to run it which 
is overkill as having 2 ways to do the same thing IMHO.


>
> The common solution is cumbersome and verbose. Why somebody would 
> prefer it over a more concise XML element is beyond me.
>

It is not really and, once again, most of maven definition can be seen as 
verbose - but here it is the same as your proposal.
If you want to tackle verbosity it is another topic whith way more items than 
this one (the artifact definition likely being inlining as a first item).


>
> You say it brings drawbacks. What are they? Please elaborate.
>

The one I listed:

1. you duplicate the definition so the pom reading is less straight forward + 
users don't know anymore where to do things 2. you break most of the tooling 
related to maven and must drop this section in the pom producer (so you dont 
solve the verbosity issue for
consumer)
3. it requires profiles to be useful for boms (not  but 
jakarta for ex) 4. it has the exact same pitfalls than 
current blocks so you will need an overrideOverride block in a few months 5. 
does not solve the broken BOM definitions which seems to be where your issue is 
coming from



>
> [1]
> https://issues.apache.org/jira/browse/MNG-4530
> https://issues.apache.org/jira/browse/MNG-5652
> https://issues.apache.org/jira/browse/MNG-1977
> 
> 
> From: Romain Manni-Bucau 
> Sent: Saturday, August 14, 2021 8:14 PM
> To: Maven Developers List 
> Subject: Re: Request for Enhancement: Dependency Overrides
>
> Le sam. 14 août 2021 à 18:56, Enno Thieleke 
>  a écrit :
>
> > You're right. Currently, if I want to control my dependencies, I 
> > must resort to excludes and define the dependencies I really want 
> > myself. And putting something like that in one or two POMs and 
> > aggregating them in a BOM is very dirty in my opinion. Not only is 
> > it noisy/verbose when it
> comes
> > to writing XML, it also adds nodes to the dependency graph where 
> > they shouldn't be - not to mention unnecessary indirections.
> > The need for overrides is becoming bigger and bigger. As the Maven 
> > ecosystem grows, artifacts with practically the same content but 
> > with different coordinates are becoming more frequent.
> >
>
> I disagree, your solution is 1-1 with existing one, just somewhere 
> else which is one pitfall as mentionned.
> It is also not new and solved since at least ten years so not sure 
> what is specific for you here and what makes the common solution less 
> practical or verbose.
>
>
>
> > Whether my proposal is about rewriting a POM dynamically is unclear 
> > at this point. I came here to propose the feature of overrides and 
> > provided
> a
> > simple PoC, not the final solution. What I consider to be clear at 
> > this point is that 

RE: [ANN] Apache Maven Wrapper 3.1.0 Released

[Christofer Dutz]

So (with my incubator mentor hat on) ...

If we update the maven-wrapper stuff currently in the repos with something we 
created with the new apache maven-wrapper-plugin ... do we still have to point 
out the related files in the LICENSE and NOTICE files?

Chris



-Original Message-
From: Jason van Zyl  
Sent: Samstag, 18. Dezember 2021 14:34
To: Maven Developers List 
Subject: Re: [ANN] Apache Maven Wrapper 3.1.0 Released

I have archived the donated project at Takari and updated the README to point 
everyone to Apache:

https://github.com/takari/maven-wrapper

jvz

> On Dec 18, 2021, at 5:52 AM, Hervé Boutemy  wrote:
> 
> The Apache Maven team is pleased to announce the release of the Apache Maven 
> Wrapper, version 3.1.0.
> 
> The Maven Wrapper is an easy way to ensure a user of your Maven build has 
> everything necessary to run your Maven build.
> 
> This is the first release of this project in its Apache Maven new home: it 
> was previously maintained by community at 
> https://github.com/takari/maven-wrapper and was kindly donated to the Maven 
> team. Thank you to all people who permitted this.
> 
> See https://maven.apache.org/wrapper/ for instructions on how to use this 
> updated Maven Wrapper.
> 
> You can download the appropriate sources etc. from the download page:
> 
> https://maven.apache.org/wrapper/download.cgi
> 
> 
> Release Notes - Maven Wrapper - Version 3.1.0
> 
> ** Bug
>* [MWRAPPER-18] - using MVNW_REPOURL, wrong Maven version is downloaded
>* [MWRAPPER-19] - maven-wrapper DefaultDownloader does not parse 
> user/password correctly
>* [MWRAPPER-20] - Maven Wrapper creates empty file when it fails behind 
> proxy 407
>* [MWRAPPER-22] - maven-wrapper on windows
>* [MWRAPPER-25] - fix installer messages
>* [MWRAPPER-37] - restore MVNW_REPOURL support for wrapper plugin
> 
> ** New Feature
>* [MWRAPPER-28] - add mvnwDebug* scripts
> 
> ** Improvement
>* [MWRAPPER-24] - mvnw calls which(1) which is an external command
>* [MWRAPPER-27] - rework mvnw* scripts to better match mvn* from Maven 3.8
>* [MWRAPPER-29] - Project should build successfully with verify lifecycle
>* [MWRAPPER-30] - Add help mojo
>* [MWRAPPER-31] - Get rid of maven-artifact-transfer
>* [MWRAPPER-32] - Use Maven core component in provided scope
> 
> ** Wish
>* [MWRAPPER-26] - install binary by default to match older user 
> experience
> 
> ** Task
>* [MWRAPPER-14] - Make maven wrapper functional
>* [MWRAPPER-17] - IP-CLEARANCE for Maven Wrapper
>* [MWRAPPER-34] - use Java 7 for maven-wrapper-plugin and maven-wrapper.jar
>* [MWRAPPER-35] - don't copy mvnwDebug* scripts by default
> 
> 
> Enjoy,
> 
> -The Apache Maven team
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For 
> additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason




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

RE: [VOTE] Release Apache Maven Wrapper version 3.1.0

[Christofer Dutz]

+1 (non-binding)

Built on Windows 10 with Java 11.0.13

Chris

[MINOR] Download all staged artifacts under the url specified in the release 
vote email.
- Archive doesn't have "apache" in its name
[OK] Verify the signature is correct.
[OK] Check if the signature references an Apache email address.
[MINOR] Verify the SHA512 hashes.
- No SHA512 hashes, just MD5 and SHA1, but these were correct.
[OK] Unzip the archive.
[OK] Verify the existence of LICENSE, NOTICE, README, RELEASE_NOTES files in 
the extracted source bundle.
- No RELEASE_NOTES
[OK] Verify the content of LICENSE, NOTICE, README, RELEASE_NOTES files in the 
extracted source bundle.
[OK] Run RAT externally to ensure there are no surprises.
[OK] Search for SNAPSHOT references: Only found some in the dummy website copy 
in the integration-tests
- SNAPSHOT references only in input to integration-tests
[OK] Search for Copyright references, and if they are in headers, make sure 
these files containing them are mentioned in the LICENSE file.
[OK] Build the project according to the information in the README.md file.
- No build instructions in README ... did a simple maven build.

-Original Message-
From: Hervé BOUTEMY  
Sent: Montag, 13. Dezember 2021 22:10
To: Maven Developers List 
Subject: [VOTE] Release Apache Maven Wrapper version 3.1.0

Hi,

We solved 18 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721=12350068=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-1679/
https://repository.apache.org/content/repositories/maven-1679/org/apache/maven/wrapper/maven-wrapper-parent/3.1.0/maven-wrapper-parent-3.1.0-source-release.zip

Source release checksum(s):
maven-wrapper-parent-3.1.0-source-release.zip sha512: 
9b7362c956cd24e21b46b290e154893ae35fd38431b6fe80f035cd17a97806e9221c71ac14975692f2a948ad25489f5b9d9bbb72441f9ab5eb541da0a86bdef9

Staging site:
https://maven.apache.org/wrapper-archives/wrapper-LATEST/

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

Vote open for at least 72 hours.

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




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


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

Mailing list threading improvements

[Christofer Dutz]

TL;DR: We’re updating how auto-generated email from Github will be
threaded on your mailing lists. If you want to keep the old defaults,
details are below.

We’re pleased to let you know that we’re tweaking the way that auto-
generated email from Github will appear on your mailing lists. This
will lead to more human-readable subject lines, and the ability of most
modern mail clients to correctly thread discussions originating on
Github.

Background: Many project mailing lists receive email auto-generated by
Github. The way that the subject lines are crafted leads to messages
from the same topic not being threaded together by most mail clients.
We’re fixing that.

The way that these messages are threaded is defined by a file -
.asf.yml - in your git repositories. We’re changing the way that it
will work by default if you don’t choose settings. If you’re happy for
us to make this change, don’t do anything - the change will happen on
October the 1st 2023.

Details of the current default, as well as the proposed changes, are on
the following page, along with instructions on how to keep your current
settings, if you prefer:

https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent

Please copy d...@community.apache.org
on any feedback.

Chris, on behalf of the Comdev PMC

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

Re: Install / Deploy plugins at the end

[Christofer Dutz]

Hi all,

In PLC4X’s build we wanted to use the deployAtEnd and were having issues (But 
this was a long time ago)

We settled on overriding the remote repo location to a directory relative to 
the build:
https://github.com/apache/plc4x/blob/develop/Jenkinsfile#L118

And then simply bulk deploy that after a successful build:
https://github.com/apache/plc4x/blob/develop/Jenkinsfile#L167
https://github.com/apache/plc4x/blob/develop/jenkins.pom#L56

Perhaps that helps?

Same should work for install.

Chris


From: Tamás Cservenák 
Date: Thursday, 20. October 2022 at 09:29
To: Maven Developers List 
Subject: Re: Install / Deploy plugins at the end
Howdy

On Thu, Oct 20, 2022 at 9:21 AM Slawomir Jaranowski 
wrote:

> You are right - issues should be closed - I will review it.
>
>
Be careful, many reproducers are INCOMPLETE.
For example, MINSTALL-102 attached test.zip is WRONG:
it mixes m-install-p versions from pom packaging and maven-archetype
packaging (lifecycle binding)!
Need to add in parent a pluginMgmt for latest 3.0.1 m-install-p, to make
all modules use the same version!

T

Re: ASF Maven credential in a project-wise token?

[Christofer Dutz]

If you run the build on asf Jenkins the credentials are there. You just need to 
inherit from the latest apache pom and it should work.

Chris

Gesendet von Outlook für Android

From: tison 
Sent: Friday, May 26, 2023 1:33:29 PM
To: Maven Developers List ; Incubator 

Subject: ASF Maven credential in a project-wise token?

Hi,

I'm configuring tokens for automatically deploying artifacts to the ASF
snapshot repository[1].

It requires configuring a user token to auth to the repository. Although
I'm wondering if I must use my personal token or if there is some
project-wise token to use. Even asking for an INFRA member to help
configure, passing over a personal token to another one increases the risk.

Best,
tison.

[1]
https://github.com/tisonkun/opendal/actions/runs/5090173050/workflow#L129

Re: GH issues and GH discussions

[Christofer Dutz]

Hi all,

I really like GH issues and discussions ... they lower the bar for contribution 
quite a bit and feel a lot more inviting for newer contributors. At least have 
we seen a significant increase in contributions since we switched to GH Issues 
and are currently starting to use GH Discussions in PLC4X.

And I should mention that I just recently had an Apache Infra PR of mine 
merged, which make it possible to format the subjects of the auto-generated GH 
emails to make them usable in normal email clients (Pior to that merge, the GH 
Discusssion emails were not configurable)

I documented the settings we use quite successfully in PLC4X and StreamPipes 
here:
https://github.com/apache/comdev-site/blob/main/source/contributors/mailing-lists.md

Hope that helps,

Chrs




From: Benjamin Marwell 
Sent: Tuesday, May 30, 2023 5:04:51 PM
To: Maven Developers List 
Subject: Re: GH issues and GH discussions

I am pretty sure if that happens (terms changes, GH not an
option), we have plenty of time to migrate.
The same has happened multiple times in the past: SourceForge, BerliOS,
Google Code...
Now it is ASF JIRA and maybe some day we will be migrating away from GitHub
Issues to something else?

But even then, there will be an archive and there will be a migration tool.
None of the above migrations
lost any data AFAIK.

Am Sa., 27. Mai 2023 um 11:24 Uhr schrieb Łukasz Dywicki <
l...@code-house.org>:

> I have no strong feelings, however relying too much on single service
> vendor is never a good idea. In this case if one day, by some
> terms changes, github repos are not an option any more, we are
> fine with ASF infrastructure. But we can't do same thing for issues
> which are embedded in GH database. If you ever found a google code
> project migrated into github/gitlab issues you know what I mean.
>
> While policies imposed on JIRA account creation, are without doubt a
> bearer to contribute first bug report, JIRA itself helps us keeping all
> ASF information together. Just to be clear - I keep being lost with new
> JIRA user interface, I'm just reflecting my personal thoughts.
>
> Best,
> Łukasz
>
>