Re: doxia-ide/eclipse
Hello, I changed the job configuration to publish the site: > https://builds.apache.org/view/M-R/view/Maven/job/doxia- > eclipse-editor/Maven-generated_Site/ > OK and it's containing the Eclipse update site: https://builds.apache.org/ > view/M-R/view/Maven/job/doxia-eclipse-editor/Maven-generated_Site/eclipse http 404 but no authent/redirection asked => would be OK. Best regards 2017-07-25 7:51 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>: > Hi Alix, > > Ah, the Jenkins job workspace is not available to anonymous. > > I changed the job configuration to publish the site: > https://builds.apache.org/view/M-R/view/Maven/job/doxia- > eclipse-editor/Maven-generated_Site/ > and it's containing the Eclipse update site: > https://builds.apache.org/view/M-R/view/Maven/job/doxia- > eclipse-editor/Maven-generated_Site/eclipse > > It should be visible to anonymous: can you check and report, please? > > If it's ok, I'll republish the content with updated link to CI result... > > Regards, > > Hervé > > Le dimanche 23 juillet 2017, 19:35:19 CEST Alix Lourme a écrit : > > Hello Hervé, > > > > The Doxia Editor Plugins Eclipse (latest build) update site > > <https://builds.apache.org/view/M-R/view/Maven/job/doxia- > eclipse-editor/ws/d > > oxia-ide-eclipse/eclipse-plugins/features/org.apache. > maven.doxia.ide.eclipse > > .feature/target/site/> seems not usable for an anonymous user :-( > > > > Best regards > > > > 2017-07-22 11:48 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>: > > > here it is: the site is updated > > > and I managed to have the build successful again > > > > > > help is still wanted to improve the plugin: most notably Markdown > support > > > is > > > missing, since it was added after Doxia 1.3 > > > > > > but all in all, the situation is better now > > > > > > Regards, > > > > > > Hervé > > > > > > Le vendredi 21 juillet 2017, 08:58:27 CEST Hervé BOUTEMY a écrit : > > > > I forgot this update site: thanks for the reminder > > > > > > > > I'll update the page to make it more visible, and add a "help wanted" > > > > text... > > > > > > > > Regards, > > > > > > > > Hervé > > > > > > > > Le mercredi 19 juillet 2017, 10:55:27 CEST Alix Lourme a écrit : > > > > > Hi, > > > > > > > > > > Perhaps this plugin doesn't build, but the Eclipse update site ( > > > > > https://maven.apache.org/doxia/doxia-ide/eclipse/eclipse/) is OK. > > > > > This plugin works fine and does the job (on Eclipse Neon.3); even > if > > > > > > is a > > > > > > > > little bugged (do not let opened an APT in workbench & delete file > in > > > > > > //). > > > > > > > > Personally I didn't found (until now) a better plugin for Maven > site > > > > > > APT > > > > > > > > edition. > > > > > > > > > > Best regards. > > > > > > > > > > 2017-07-19 9:41 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>: > > > > > > Hi, > > > > > > > > > > > > I used this plugin a few years ago, then it started to misbehave > > > > > > when > > > > > > upgrading Eclipse version. And now, it even does not build any > more: > > > > > > looks > > > > > > like something changed in Eclipse ecosystem > > > > > > > > > > > > I'll update the page to tell that this plugin does not even build > > > > > > any > > > > > > more: > > > > > > help wanted... > > > > > > > > > > > > Regards, > > > > > > > > > > > > Hervé > > > > > > > > > > > > Le lundi 17 juillet 2017, 18:18:10 CEST Bruce Wen a écrit : > > > > > > > Hi All, > > > > > > > > > > > > > > I found the eclipse update sites provided in this page do not > > > > > > > work: > > > > > > > > > > > > > > https://maven.apache.org/doxia/doxia-ide/eclipse/ > > > > > > > > > > > > > > Bruce Wen > > > > > > > > > > > > > > > > > > - > > > > > > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > - > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Alix Lourme
Re: doxia-ide/eclipse
Hello Hervé, The Doxia Editor Plugins Eclipse (latest build) update site <https://builds.apache.org/view/M-R/view/Maven/job/doxia-eclipse-editor/ws/doxia-ide-eclipse/eclipse-plugins/features/org.apache.maven.doxia.ide.eclipse.feature/target/site/> seems not usable for an anonymous user :-( Best regards 2017-07-22 11:48 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>: > here it is: the site is updated > and I managed to have the build successful again > > help is still wanted to improve the plugin: most notably Markdown support > is > missing, since it was added after Doxia 1.3 > > but all in all, the situation is better now > > Regards, > > Hervé > > Le vendredi 21 juillet 2017, 08:58:27 CEST Hervé BOUTEMY a écrit : > > I forgot this update site: thanks for the reminder > > > > I'll update the page to make it more visible, and add a "help wanted" > > text... > > > > Regards, > > > > Hervé > > > > Le mercredi 19 juillet 2017, 10:55:27 CEST Alix Lourme a écrit : > > > Hi, > > > > > > Perhaps this plugin doesn't build, but the Eclipse update site ( > > > https://maven.apache.org/doxia/doxia-ide/eclipse/eclipse/) is OK. > > > This plugin works fine and does the job (on Eclipse Neon.3); even if > is a > > > little bugged (do not let opened an APT in workbench & delete file in > //). > > > Personally I didn't found (until now) a better plugin for Maven site > APT > > > edition. > > > > > > Best regards. > > > > > > 2017-07-19 9:41 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>: > > > > Hi, > > > > > > > > I used this plugin a few years ago, then it started to misbehave when > > > > upgrading Eclipse version. And now, it even does not build any more: > > > > looks > > > > like something changed in Eclipse ecosystem > > > > > > > > I'll update the page to tell that this plugin does not even build any > > > > more: > > > > help wanted... > > > > > > > > Regards, > > > > > > > > Hervé > > > > > > > > Le lundi 17 juillet 2017, 18:18:10 CEST Bruce Wen a écrit : > > > > > Hi All, > > > > > > > > > > I found the eclipse update sites provided in this page do not work: > > > > > > > > > > https://maven.apache.org/doxia/doxia-ide/eclipse/ > > > > > > > > > > Bruce Wen > > > > > > > > ---- > - > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Alix Lourme
Re: doxia-ide/eclipse
Hi, Perhaps this plugin doesn't build, but the Eclipse update site ( https://maven.apache.org/doxia/doxia-ide/eclipse/eclipse/) is OK. This plugin works fine and does the job (on Eclipse Neon.3); even if is a little bugged (do not let opened an APT in workbench & delete file in //). Personally I didn't found (until now) a better plugin for Maven site APT edition. Best regards. 2017-07-19 9:41 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>: > Hi, > > I used this plugin a few years ago, then it started to misbehave when > upgrading Eclipse version. And now, it even does not build any more: looks > like something changed in Eclipse ecosystem > > I'll update the page to tell that this plugin does not even build any more: > help wanted... > > Regards, > > Hervé > > Le lundi 17 juillet 2017, 18:18:10 CEST Bruce Wen a écrit : > > Hi All, > > > > I found the eclipse update sites provided in this page do not work: > > > > https://maven.apache.org/doxia/doxia-ide/eclipse/ > > > > Bruce Wen > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Alix Lourme
Re: Maven password encryption by project
Hi Jim, Thanks for your feedback, my answer in the text. 2017-03-17 21:51 GMT+01:00 Jim Klo <jim@sri.com>: > As others have mentioned, you shouldn’t be storing passwords in a POM. > Fully agree :) > > I as well don’t have a great corporate solution that works for secrets > management for maven. > > My solution has been to use Environment Variables - which basically > follows the same pattern that AWS, Docker, Vagrant and others utilize. > The pattern requires you to define a convention so that your secret is > set into a predictable environment variable from which you can then use > within your POM, script, etc while the job is running. > > As far as for local users - generally this can be a one time setup, then > from there you don’t need to monkey with credentials ever again until you > have to cycle. You shouldn’t need to share any credentials. > > This works well because unless you echo the environment, secret info isn’t > echoed into the logs. And it can be utilized for non-secret information as > well. > I agree environment variables could be a sustainable solution. But for "local" builds (developers who works on own machine) it could be a little tricky when they work on many projects: you should know & configure some/many environment variables before the project build after checkout. In a company, in could be hard to deploy a process like that based on some "convention name" (on some environment variable). The precept of "checkout, build ... it should works" is important to kept. Currently, we have deploy a system of private key "by project" (=> generally the development team perimeter, who work on one or some Maven projects). It allow to encrypt some credentials (technical account, tokens, ... used in project build like application server deployment), decrypted as Maven properties during build. So the prerequisite of concept of "checkout, build ... it works" is just to have the private key of this project perimeter. This process has some inconvenients (sharing some credentials like Charles said, specificity on CI agents for this private key availability, ...), requires some dedicated plugin (inherited from pom company), but it does the job since 10 years: give a minimal security level, simple to use. My wish is today to switch on the best practices for that (credentials encryption), but keeping the simplicity of usage (among few hundred developers; the level of Maven mastery is not the same for all). > > On Mar 17, 2017, at 6:38 AM, Alix Lourme <alix.lou...@gmail.com> wrote: > > I'm searching the best practice for password encryption in a maven POM > file *by > project*, could by used by properties (like in ANT or WAGON). Sample : > --- > >maven-antrun-plugin >1.8 > > > > > todir="cert" trust="yes" /> > > > > --- > > In this case, my *docker.password* could be a properties (pom or > settings.xml) but must not be in clear text. > > > Is there a reason you’ve not using an identity file instead for this > situation? It would likely work better, and you could pass the identity > file as a secret file, from a separate system, repository, or local > configuration for running the build. > It was just a snippet to explicit the problem. Many various Maven plugins or configuration requires user/password configuration, who should provided by Maven property but not in pom (=> with settings.xml, environment variable, or other process like specific plugin explained previously); and it is better if this property is not written in clear text in any files. > > > The problem with Maven encryption > <https://maven.apache.org/guides/mini/guide-encryption.html>: > - I have a master password defined in *settings-security.xml* (locally) for > my user need (like proxy password encryption in MY *settings.xml*) > - The CI tools contains the same mechanism (own *settings-security.xml*) > for global needs, like server encryption used in *settings.xml* for jar > publication in repository ; and I can't retrieve this file > > > AFAIK maven encryption only applies to elements. Others can > chime in, but not sure that this would solve your specific problem anyways. > Does your CI solution have some kind of mechanism for retrieving or > providing secret information/files? This seems to be the root of your > problem. > Maven encryption works for all properties in settings. CI platform have some "global" credentials to facilitate/promote the usage of (exemple) Maven website publication, SonarQube analysis. I agree it could be considered as evil, but this solution allows: - To deploy massively some process (doc, quality, ...) for
Re: Maven password encryption by project
Hi Karl Heinz, Charles, Justin, Curtis
Many thanks for your feedbacks.
[Karl Heinz] I would suggest to put them into the settings.xml file outside
> your pom file, cause the pom file will be checked in into version control
> system..
>
I agree it is the most simple way, but if all users (and the CI platform)
have not the same *settings-security.xml *file (and they should not), the
passwords should be in clear :-(.
[Charles] It sounds as though you wish to share a credential set amount
> multiple users. This is an example of what the security community calls “a
> bad idea”.
>
For the project perimeter yes. When you have some multiple credentials for
one project (deploy on repository, push on quality platform, publish on
staging platform, ...), I don't see how project team can't share this
credentials or tokens ; if you want a simple process to use.
I agree that having one settings.xml by project with your own credentials
or an only settings.xml with your credentials for each projects is better
... but when you work on many projects in same time, it is a little hard to
deal with that.
[Justin] You might want to look into secrets management tools such as Vault
> from HashiCorp and KeyWhiz from Square.
>
Thanks for this link, I will see how to use it/them with Maven ecosystem.
[Curtis] For what it's worth, here is how the ImageJ project does it for
> Travis CI [...]
>
I agree it is the most elegant solution without a central secret platform
management.
Credentials are not shared, but I understand this is a bad practice ;-)
I will see how manage a secret by projects in our CI platform.
In short, I did not want launch a troll on what is good or not :-) ... just
have an idea of the best practice used to manage passwords (simply) for
teams working on multiple projects.
The access problems are often a waste of time when you have some project
team turnover (even is security is important), I always dream of a simple
way how resolve that :-)
Have a good weekend all.
Best regards
2017-03-17 16:05 GMT+01:00 Curtis Rueden <ctrue...@wisc.edu>:
> Hi Alix,
>
> For what it's worth, here is how the ImageJ project does it for Travis CI
> builds:
>
> https://github.com/imagej/imagej/blob/2bfd8a23a5ff427fabe12ea3f71146
> 04e8485a75/.travis.yml
> https://github.com/imagej/imagej/blob/2bfd8a23a5ff427fabe12ea3f71146
> 04e8485a75/.travis/build.sh
> https://github.com/imagej/imagej/blob/2bfd8a23a5ff427fabe12ea3f71146
> 04e8485a75/.travis/settings.xml
>
> To summarize the key points:
>
> * The build invokes mvn with "--settings .travis/settings.xml", which is a
> settings.xml committed to SCM
> * This settings.xml uses "${env.MAVEN_PASS}" for the password.
> * This MAVEN_PASS environment variable is stored encrypted in the
> .travis.yml file; see:
> https://docs.travis-ci.com/user/environment-variables/
>
> In our case, we are fine hardcoding the Maven deploy user as "travis", but
> of course you could also make that configurable with MAVEN_USER variable or
> similar.
>
> For manual deployment, developers use their own ~/.m2/settings.xml with
> their own credentials—i.e., for us, the .travis/settings.xml is _only_ for
> Travis builds.
>
> HTH,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - https://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>
>
> On Fri, Mar 17, 2017 at 8:38 AM, Alix Lourme <alix.lou...@gmail.com>
> wrote:
>
> > Dear community,
> >
> > I'm searching the best practice for password encryption in a maven POM
> > file *by
> > project*, could by used by properties (like in ANT or WAGON). Sample :
> > ---
> >
> > maven-antrun-plugin
> > 1.8
> >
> >
> >
> >
> > > todir="cert" trust="yes" />
> >
> >
> >
> > ---
> >
> > In this case, my *docker.password* could be a properties (pom or
> > settings.xml) but must not be in clear text.
> >
> > The problem with Maven encryption
> > <https://maven.apache.org/guides/mini/guide-encryption.html>:
> > - I have a master password defined in *settings-security.xml* (locally)
> for
> > my user need (like proxy password encryption in MY *settings.xml*)
> > - The CI tools contains the same mechanism (own *settings-security.xml*)
> > for global needs, like server encryption used in *settings.xml* for jar
> > publication in repository ; and I can't retrieve this file
> >
> > => I can't use this mechanism for password encryption who works locally
> and
> > on the CI server.
> >
> > *Is there a way to h
Maven password encryption by project
Dear community, I'm searching the best practice for password encryption in a maven POM file *by project*, could by used by properties (like in ANT or WAGON). Sample : --- maven-antrun-plugin 1.8 --- In this case, my *docker.password* could be a properties (pom or settings.xml) but must not be in clear text. The problem with Maven encryption <https://maven.apache.org/guides/mini/guide-encryption.html>: - I have a master password defined in *settings-security.xml* (locally) for my user need (like proxy password encryption in MY *settings.xml*) - The CI tools contains the same mechanism (own *settings-security.xml*) for global needs, like server encryption used in *settings.xml* for jar publication in repository ; and I can't retrieve this file => I can't use this mechanism for password encryption who works locally and on the CI server. *Is there a way to have a encryption mechanism for the project's perimeter ?* (and not for user's perimeter, current Maven encryption works perfectly for that). --- Using -s and -gs Maven options (=> user/global settings override) could be a workaround but : - Server item definition or properties defining password must be in clear text - Using this Maven settings for each build depending the project workspace is a little boring Perhaps is there a best way like a "private key by project" ... but I didn't found entry point about that. Thanks in advance. Best regards *NB*: This question was firstly on stackoverflow <https://stackoverflow.com/questions/33784790/maven-password-encryption-by-project>, but no really interest ^^. -- Alix Lourme
Re: Plugin assembly: Howto use 'single' goal as an agregator ?
Hi Curtis, Why not stick with the old version of maven-assembly-plugin until you have > to refactor your build more thoroughly? > I thought to that, but it collides another (philosophical) concept: to use always the last version of plugins ! ^^ More seriously and to explain, the "problem" is that the configuration is inside a company parent pom, and the CI has some template builds containing this assembly call. This refactor is simple for a project, but more difficult to instruct on many many projects. So not upgrading the plugin version is just delay the problem ... In short, this is the classic life of components migration for a company, and when you don't really consider a depreciation tag :-) But if it is not technically possible (aggregation by pom configuration), I will take the problem by the horns. Many thanks for the informations and suggestions. Best regards 2017-03-14 19:29 GMT+01:00 Curtis Rueden <ctrue...@wisc.edu>: > Hi Alix, > > Why not stick with the old version of maven-assembly-plugin until you have > to refactor your build more thoroughly? > > Regards, > Curtis > > -- > Curtis Rueden > LOCI software architect - https://loci.wisc.edu/software > ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden > > > On Tue, Mar 14, 2017 at 1:06 PM, Alix Lourme <alix.lou...@gmail.com> > wrote: > > > Hello, > > > > Even if using aggregator is not a good practice in this case ... if there > > is a technical possibility to force the aggregation for a goal by pom > > configuration, I'll take it. > > Because after continuing to dig, I am in a dead-end ^^ > > > > Many thanks. > > Best regards > > > > 2017-03-14 10:45 GMT+01:00 Alix Lourme <alix.lou...@gmail.com>: > > > > > Hi Karl Heinz, > > > > > > Thanks for your answer (and sorry for mine late). > > > > > > the best thing to create a separate module in your build with packaging > > >> pom and only put the maven-assembly-plugin in it and bind it to the > life > > >> cycle > > >> This is simply a good way of following single responsibility > principle. > > >> > > > try to get it as simple as possible which will result in just: mvn > clean > > >> package. > > >> > > > > > > I'm fully agree with you (there is no debate), and this is an objective > > to > > > achieve in the future ... > > > > > > But ... when you have many projects (multiple hundred) using this bad > > way (*mvn > > > install assembly:attached*): > > > * Upgrading a parent (company pom) & changing a 'goal' is simple > > > * Reviewing completely the archive generation process (new module, > > > descriptor content) is a little bit more complicated > > > > > > So I hoped for a consensus to accompagn the transition > > > (maven-assembly-plugin v3.0.0) without project structure change :-). > > > I will affine pro & cons and ruling on the possibilities. > > > > > > > > > What I don't understand is your reference to maven-release-plugin and > > >> maven-invoker-plugin ? > > >> > > > > > > When you are using the previous (bad) way on maven-release-plugin, you > > > could define goals > > > <https://maven.apache.org/maven-release/maven-release- > > plugin/perform-mojo.html#goals> > > > with: *-Dgoals="install assembly:attached".* The result is "one Maven > > > command" like: > > > -- > > > > > > [DEBUG] Executing: cmd.exe /X /C ""C:\[...]\mvn.bat" -B -X -D > > > maven.repo.local=C:\[...]\.m2\repository -f myApp -s > > > C:\[...]\AppData\Local\Temp\release-settingsXXX.xml -D > > > performRelease=true -P someProfiles install assembly:attached" > > > -- > > > This reference to maven-release-plugin or invoker was just an argument > > for > > > a "only one Maven command" need ; avoiding ideas like: "*Just do two > step > > > command, 'mvn install' and after 'mvn assembly:attached*'" > > > > > > Thanks > > > Best regards > > > > > > 2017-03-11 16:31 GMT+01:00 Karl Heinz Marbaise <khmarba...@gmx.de>: > > > > > >> Hi, > > >> > > >> If you like to produce a package (zip/tar/whatever kind of > > >> archive/bundle) which contains some modules/artifacts etc. from your > > multi > > >> module build it is the best thing to create a separate module in y
Re: Plugin assembly: Howto use 'single' goal as an agregator ?
Hello, Even if using aggregator is not a good practice in this case ... if there is a technical possibility to force the aggregation for a goal by pom configuration, I'll take it. Because after continuing to dig, I am in a dead-end ^^ Many thanks. Best regards 2017-03-14 10:45 GMT+01:00 Alix Lourme <alix.lou...@gmail.com>: > Hi Karl Heinz, > > Thanks for your answer (and sorry for mine late). > > the best thing to create a separate module in your build with packaging >> pom and only put the maven-assembly-plugin in it and bind it to the life >> cycle >> This is simply a good way of following single responsibility principle. >> > try to get it as simple as possible which will result in just: mvn clean >> package. >> > > I'm fully agree with you (there is no debate), and this is an objective to > achieve in the future ... > > But ... when you have many projects (multiple hundred) using this bad way > (*mvn > install assembly:attached*): > * Upgrading a parent (company pom) & changing a 'goal' is simple > * Reviewing completely the archive generation process (new module, > descriptor content) is a little bit more complicated > > So I hoped for a consensus to accompagn the transition > (maven-assembly-plugin v3.0.0) without project structure change :-). > I will affine pro & cons and ruling on the possibilities. > > > What I don't understand is your reference to maven-release-plugin and >> maven-invoker-plugin ? >> > > When you are using the previous (bad) way on maven-release-plugin, you > could define goals > <https://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#goals> > with: *-Dgoals="install assembly:attached".* The result is "one Maven > command" like: > -- > > [DEBUG] Executing: cmd.exe /X /C ""C:\[...]\mvn.bat" -B -X -D > maven.repo.local=C:\[...]\.m2\repository -f myApp -s > C:\[...]\AppData\Local\Temp\release-settingsXXX.xml -D > performRelease=true -P someProfiles install assembly:attached" > -- > This reference to maven-release-plugin or invoker was just an argument for > a "only one Maven command" need ; avoiding ideas like: "*Just do two step > command, 'mvn install' and after 'mvn assembly:attached*'" > > Thanks > Best regards > > 2017-03-11 16:31 GMT+01:00 Karl Heinz Marbaise <khmarba...@gmx.de>: > >> Hi, >> >> If you like to produce a package (zip/tar/whatever kind of >> archive/bundle) which contains some modules/artifacts etc. from your multi >> module build it is the best thing to create a separate module in your build >> with packaging pom and only put the maven-assembly-plugin in it and bind it >> to the life cycle. This project contains all the needed dependencies in >> your assembly project pom...which should be packaged into your resulting >> archive (zip/tar/whatever). >> >> The assembly descriptor contains the appropriate >> dependencySets/moduleSets/sources etc. entries as needed. >> >> This makes it absolutely sure that using a simple: >> >> mvn clean package >> >> or >> >> mvn install >> >> everything is correctly packaged into the resulting bundle you would like >> to build. >> >> This is simply a good way of following single responsibility principle. >> >> >> This produces each time a correct and the same result in contradiction to >> your supplemental goal calling from command line (you just simply miss it?). >> >> Apart from that using fileSets is usually not the correct way cause it >> relies on the content which is on the file system which might sometimes not >> what you really like if you don't do: >> >> mvn clean >> >> before. >> >> If you do things like this: >> >> mvn install >> ...Doing something here... >> mvn install assembly:attached >> >> The resulting bundle which has been produced by using assembly:attached >> could contain artifacts which are not part of the build.. >> >> This is also an problem in reproducibility of builds. >> >> From my point of view a single command like this: >> >> >> mvn clean package >> >> is easier and more in the paradigm of Maven. Use conventions... >> >> Adding a supplemental call to a plugin goal does not make it easier.. >> >> I will rely on just the build as it...without using supplemental goals or >> using some properties needed to be defined on the command line which I >> often see in other projects where you need to call some goals of plugins &g
Re: Plugin assembly: Howto use 'single' goal as an agregator ?
Hi Karl Heinz, Thanks for your answer (and sorry for mine late). the best thing to create a separate module in your build with packaging pom > and only put the maven-assembly-plugin in it and bind it to the life cycle > This is simply a good way of following single responsibility principle. > try to get it as simple as possible which will result in just: mvn clean > package. > I'm fully agree with you (there is no debate), and this is an objective to achieve in the future ... But ... when you have many projects (multiple hundred) using this bad way (*mvn install assembly:attached*): * Upgrading a parent (company pom) & changing a 'goal' is simple * Reviewing completely the archive generation process (new module, descriptor content) is a little bit more complicated So I hoped for a consensus to accompagn the transition (maven-assembly-plugin v3.0.0) without project structure change :-). I will affine pro & cons and ruling on the possibilities. What I don't understand is your reference to maven-release-plugin and > maven-invoker-plugin ? > When you are using the previous (bad) way on maven-release-plugin, you could define goals <https://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#goals> with: *-Dgoals="install assembly:attached".* The result is "one Maven command" like: -- [DEBUG] Executing: cmd.exe /X /C ""C:\[...]\mvn.bat" -B -X -D maven.repo.local=C:\[...]\.m2\repository -f myApp -s C:\[...]\AppData\Local\Temp\release-settingsXXX.xml -D performRelease=true -P someProfiles install assembly:attached" -- This reference to maven-release-plugin or invoker was just an argument for a "only one Maven command" need ; avoiding ideas like: "*Just do two step command, 'mvn install' and after 'mvn assembly:attached*'" Thanks Best regards 2017-03-11 16:31 GMT+01:00 Karl Heinz Marbaise <khmarba...@gmx.de>: > Hi, > > If you like to produce a package (zip/tar/whatever kind of archive/bundle) > which contains some modules/artifacts etc. from your multi module build it > is the best thing to create a separate module in your build with packaging > pom and only put the maven-assembly-plugin in it and bind it to the life > cycle. This project contains all the needed dependencies in your assembly > project pom...which should be packaged into your resulting archive > (zip/tar/whatever). > > The assembly descriptor contains the appropriate > dependencySets/moduleSets/sources etc. entries as needed. > > This makes it absolutely sure that using a simple: > > mvn clean package > > or > > mvn install > > everything is correctly packaged into the resulting bundle you would like > to build. > > This is simply a good way of following single responsibility principle. > > > This produces each time a correct and the same result in contradiction to > your supplemental goal calling from command line (you just simply miss it?). > > Apart from that using fileSets is usually not the correct way cause it > relies on the content which is on the file system which might sometimes not > what you really like if you don't do: > > mvn clean > > before. > > If you do things like this: > > mvn install > ...Doing something here... > mvn install assembly:attached > > The resulting bundle which has been produced by using assembly:attached > could contain artifacts which are not part of the build.. > > This is also an problem in reproducibility of builds. > > From my point of view a single command like this: > > > mvn clean package > > is easier and more in the paradigm of Maven. Use conventions... > > Adding a supplemental call to a plugin goal does not make it easier.. > > I will rely on just the build as it...without using supplemental goals or > using some properties needed to be defined on the command line which I > often see in other projects where you need to call some goals of plugins > before or after things. I will alway try to get it as simple as possible > which will result in just: mvn clean package. > > What I don't understand is your reference to maven-release-plugin and > maven-invoker-plugin ? > > > Kind regards > Karl Heinz Marbaise > > > On 11/03/17 15:56, Alix Lourme wrote: > >> Hello, >> >> Since maven-assembly-plugin v3.3.0, the *attached* goal has been removed ( >> MASSEMBLY-704 <https://issues.apache.org/jira/browse/MASSEMBLY-704>). >> >> This *attached* goal was an aggregator (v2.6 source >> <https://svn.apache.org/repos/asf/maven/plugins/tags/maven-a >> ssembly-plugin-2.6/src/main/java/org/apache/maven/plugin/ass >> embly/mojos/AttachedAssemblyMojo.java>) >> but not th
Plugin assembly: Howto use 'single' goal as an agregator ?
Hello, Since maven-assembly-plugin v3.3.0, the *attached* goal has been removed ( MASSEMBLY-704 <https://issues.apache.org/jira/browse/MASSEMBLY-704>). This *attached* goal was an aggregator (v2.6 source <https://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-2.6/src/main/java/org/apache/maven/plugin/assembly/mojos/AttachedAssemblyMojo.java>) but not the *single* goal (v3.0.0 source <https://svn.apache.org/repos/asf/maven/plugins/tags/maven-assembly-plugin-3.0.0/src/main/java/org/apache/maven/plugins/assembly/mojos/SingleAssemblyMojo.java> ). Even *attached* goal "*leads to non-standard builds*", it was very useful on a multi modules project to generate a bundle with some modules items (artifacts, anything produced on *package* phase, ...) when the descriptor contains only *fileSets* definitions, using only one Maven command (e.g.: "*mvn install assembly:attached*") ; because assembly executed after package/install/deploy phase in each modules. With module binaries <https://maven.apache.org/plugins/maven-assembly-plugin/faq.html#module-binaries> configuration, this job could be done ; but forces reviewing all assembly descriptors (usage of *moduleSet* in addition of *fileSet*), or using two steps Maven command. If you consider that using one command is a prerequisite ( *maven-release-plugin* plugin usage or some jobs with *maven-invoker*), the v2.x -> v3.x *maven-assembly-plugin* migration could be a little tricky. => Is there a way to execute single goal as an aggregator, via pom configuration (inheritable from a super/company parent pom) ? With that the *migration *could be just to replace *attached* by *single*. Many thanks in advance for tips or idea Best regards -- Alix Lourme
