Re: [Proposal] EasyVersionMaintenance
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Brian,
First question, wouldn't ${project.version} solve the use case of
updating same versioned dependencies?
Nope. It would help in some of my business projects where
all artifacts get the same version when released, but
I already have a simple workaround to solve this.
In my major open-source-project I have a lot of modules
with various inter-project dependencies. Here I have
individual release cycles per module and have a
real maintenance hell with maven. I tried release-plugin
multiple times but gave up. I also talked with the
release-plugin evangelists but they want me to believe
in their religion and organize my project in the way
that they think what does not fit for me at all.
Also: A version that was omitted in a dependency section can only
be resolved if the referenced modules are resolved. So if it is NOT
part of the sub-tree where the build was invoked we have a problem to
solve. However this can be done by adding a list of projects named
closure similar to the reactor but that is build from the
toplevel-pom recursively following the modules.
This doesn't work unless you have a whole project checked out on disk.
You couldn't resolve from a repository because the module entry refers
to a subfolder of where to pom is, but in a repository it's
meaningless...ie it has no complete coordinates.
Exactly. You got it and this is what I want and what my
proposal is all about.
Therefore I wrote about the two views on a pom in my proposal.
I also thought I clearly explained that an omitted version will
never get deployed to a repository and this only applies to
development view when a POM is read as pom.xml from local disc.
You maybe never had these problems when you work with single
or few modules at a time. Or these modules/artifacts are not that
dependent. But if you have a project with 50, 100 or more
modules with a large dependency tree and you want to release
some common-modules and then want to ensure that further releases
of modules that depend on that will be tested and released
based on the current releases of the common-modules you will
get a little crazy. Especially when there are some few modules
that by intention use an older version of some common-module.
Maybe you should think of what if apache.org was maintained
in one single module tree by one developer that rolls a dice
every day to decide in which module to work today.
Besides wasting all his time to get into that code before
being productive he might get lost in maintaining the
versions of commons-* or whatever in all other projects
after doing releases.
This is a very crazy scenario but comes close to my problem.
Regards
Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkp3SJwACgkQmPuec2Dcv/8pBwCffyhyVCZ9GaT+B1HkGw4dOsoM
d9gAn25Xi4B+/WRu1rppTIphR7GcsMr2
=1dA1
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Trade-Off with pluginManagement in Super-Pom
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Fox wrote: Therefore I think that the pluginManagement in Super-Pom caused some trouble and confusion that you might not be aware of. It should use the version even if you invoke directly from the command line, if not, that's a separate bug. To say it very precisely: I have ... reporting plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.5/version ... I do not even think that it is a bug that the commandline is not affected by the version in reporting-section. IMHO it should only be affected by the version in the build-section. It is just the problem that a user might not think that he has to modify his pom in order to be able to invoke a new goal documented on the web on the comandline or to use this extraordinary greedy syntax. At least for me it took a little while until I got it and many users might have less insight of maven. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp3SmkACgkQmPuec2Dcv//ALQCfUWpq2E1lN1XCuD/DrZBcTUUi 8rcAn2taDKA/65WCQlhwl2S4VFjJpKSO =W1+7 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Trade-Off with pluginManagement in Super-Pom
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Brian, On Fri, Jul 24, 2009 at 4:36 PM, Joerg Hohwillerjo...@j-hohwiller.de wrote: Hi there, I read the documentation of javadoc-plugin about goal aggregate. Then I called mvn javadoc:aggregate and maven failed saying that the goal aggregate does not exist. mvn -U javadoc:aggregate, same result. Website wrong? Aha... think... mvn javadoc:2.5:aggregate, error mvn maven-javadoc-plugin:2.5:aggregate, error mvn org.apache.maven.plugins:maven-javadoc-plugin:2.5:aggregate, works! Do not get me wrong. I really love the idea of having fixed plugin versions in super-pom. However my example shows the possible confusion and a quite greedy syntax. Besides my pom.xml has version to 2.5 for javadoc-plugin but NOT in pluginManagement. I should change my pom.xml though... Your version in the pom will override the version in pluginManagement. Thanks for your response, but I am not quite sure that you got what I wanted to say. The version in pom only applies to commandline if it is set in pluginManagement. If I do not set it there the commandline needs a very greedy syntax to specify the version where I used to just call mvn -U javadoc:aggregate for using the latest version of javadoc-plugin. It is still downloaded but not used. Therefore I think that the pluginManagement in Super-Pom caused some trouble and confusion that you might not be aware of. Regards Jörg Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpwub8ACgkQmPuec2Dcv/8NCQCeI/eZ8JiOr4VhQ3ig2Eh6vWex cqwAmwYZXtViVH0V/A6/qM7HY39PbkM8 =fysT -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Proposal] EasyVersionMaintenance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Brett, Thanks for taking care. I already thought that this will gonna be ignored. So the summary is that if omitted on a dependency, the group ID and version should match that of the current project, and on deployment it needs to be populated? Yes, correctly - at least the version is the important one for omitting, I have no need for omitting groupId. DependencyManagement should still overrule for compatibility reasons. If it is all just that easy as you point it out ;) Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpwwx0ACgkQmPuec2Dcv/8khQCdEMSSc/JrXVNfwMTGbEfOASHe Mx8An3DskYpBA7xhLbzMA3Ohz7NvTipN =H6YW -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
MOJO-1368 - unable to find resource 'VM_global_library.vm'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, could someone have a look at https://jira.codehaus.org/browse/MOJO-1368 If I am right, this should be moved to MSITE. This bug is what we all see since years. If someone was so kind to explain how to solve this, it would be nice if this could be fixed. Take care Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpwz+AACgkQmPuec2Dcv/9t+QCeJDouqZwyk3kfTjR+Bq/rOQVj 05kAnje+ac4238+9FTo7lqSVWz6KGWa3 =3s0z -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: site plugin release planning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Hello, I was looking at the jira roadmap for the site plugin, thinking about a release plan for 2.1. The main change so far is the upgrade to doxia 1.1, I think it would be a good idea to concentrate the next release on issues that are related that. In particular, I'd like to fix all these annoying bugs with links (eg MSITE-395, MSITE-404, MSITE-409 and many others), which might necessitate another doxia release. great to hear. Did already someone report that if distributionManagement is present but has no site then site:stage fails. This is bad if you need to have distributionManagement for having a repository section. I personally think that the entire distributionManagement in the pom.xml was a design mistake because this is something that should be covered by settings.xml but however... I currently comment out my distributionManagement to invoke site:stage and get the expected result because with a site section wired subfolders are created that break my rsync-script. Shall I file a jira ticket or is this already known? Right now there are also a number of other issues scheduled that are not related (eg MSITE-79, MSITE-206, MSITE-326) which I would like to leave out and schedule for a later release. Is this ok with everyone? -Lukas +1 for me but I am no committer... Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpqCEsACgkQmPuec2Dcv/8w4gCePN6jqbMPLVb28Kfh30ETeyf7 jqIAoJbE6jMzKn0AN/4lSuk8B1boGmWN =P0+H -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Trade-Off with pluginManagement in Super-Pom
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I read the documentation of javadoc-plugin about goal aggregate. Then I called mvn javadoc:aggregate and maven failed saying that the goal aggregate does not exist. mvn -U javadoc:aggregate, same result. Website wrong? Aha... think... mvn javadoc:2.5:aggregate, error mvn maven-javadoc-plugin:2.5:aggregate, error mvn org.apache.maven.plugins:maven-javadoc-plugin:2.5:aggregate, works! Do not get me wrong. I really love the idea of having fixed plugin versions in super-pom. However my example shows the possible confusion and a quite greedy syntax. Besides my pom.xml has version to 2.5 for javadoc-plugin but NOT in pluginManagement. I should change my pom.xml though... Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpqGzsACgkQmPuec2Dcv/+mvgCggQprLsuE09O3DV4mPOjXiTqA oZQAn3pw8Vrg77t1B0ktSzhLt5VxZ22R =BXTx -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[Proposal] EasyVersionMaintenance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everybody, I updated my proposal and now think it is consistent and understandable. However the examples traces still require some thoughts but you should get the idea easily. And finally here it is: http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance Feedback is very appreciated. Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpovlwACgkQmPuec2Dcv/8P2wCfdFEZ0fZQNdvWSHLNLxcNiiYu 8+UAnReoRks9nrg0pf3k6Bv1YHmAajW5 =MTsq -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven and maintaining version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again, Quite impressive list. So there seems to be a high demand in this topic. Maybe we should bring some things together. I wrote this proposal: http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance I would really love to get some feedback like * totally useless * awesome, all I ever dreamed of * nice idea, but will not work in case of XYZ * cool but would mean to rewrite maven from scratch * well this already works with maven-magic-plugin * ... Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoRvBwACgkQmPuec2Dcv/9q/wCfTy2DSFvsvIbTzOszg5TdoCri 0RQAnjAseeaLzeFXMw7Kxre75Sl9uvgS =XqPp -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Brian, Do you need simple IT-projects that I shall attach to MNG-4161 and related? Sample ITs for sure, and some level of detail in a proposal like these: http://docs.codehaus.org/display/MAVENUSER/User+Proposals here is my proposal: http://docs.codehaus.org/display/MAVENUSER/EasyVersionMaintenance Let me know if somethings missing or wrong. BTW: is there a chance to have such feature running in a usable version of maven (NOT a official release) in a couple of month? If we are talking about something that will go into 3.x and is NOT usable before 2010, I rather put my energy in a simple front-end that handles this feature and then delegates to maven. Take care Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoPH6UACgkQmPuec2Dcv/8JrgCfQXNZXlA/c/NcA+aJywZ7s8bt LJMAnjyKgoyEfhPk8k299FjJvLS7l8j3 =xAY4 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ralph,
Okay. So thats what I guessed when I said that the MavenProject/Model is
just a stupid POJO and various plugins manipulate it with side effects.
Sounds a little hacky to me but thats the way it is. So my serialization
idea is nuts though.
Anyhow I think that if you have some information in memory, you should
NOT have to write it to the disc so that someone else can copy (read
and write)
it again. I thought that you store the transformed XML in that new string
attribute (was it alternativeRepresentation) so the Installer/Deployer
could write this string if available instead of copying the pom.xml as
is.
I think you are referring to one of the other patches that was
submitted, not what I committed to the MNG-624 branch.
A big problem could be the encoding issue if you store XML in a string
and then want to save it with some Writer, you need to know the encoding
from the XML-header or you run into trouble.
My fix didn't store the XML in a string, it modified the DOM.
After getting more of the big picture, I think your idea is good to
write a new pom.xml to ${project.build.directory} and copy that on
install/deploy. This would also solve the needs behind something like
MINSTALL-50 (e.g. by some plugin that does a post-transformation on the new
pom).
Regards
Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoPJrQACgkQmPuec2Dcv/+ZMwCeNp/rE8KTH0sNeVuDHQ1zeOuD
mtYAn0B6p8XlqT7oan9na/POHJ4LZ4qW
=JvQY
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven 2.1 incompatibility list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, E.g. with maven 2.0.x you could have a module included in your toplevel pom that you also add as dependency to some plugin such as checkstyle or findbugs. In maven 2.1 you have to remove the module declaration or you will get a cyclic dependency error (that is hard to unserstand since it says that some module depends on itself - which is right but you can not see this in its pom directly because it is inherited). I think that's a bug. Having a plugin in the same reactor is bad, but building something and then passing it to a plugin is valid imo. I've had to do that to work around not being able to build and use a plugin in the same build. Actually what I did was suggested in the documentation of checkstyle-plugin and/or findbugs-plugin. So shall I on a bug in JIRA? Additionally with maven 2.0.x you could have the same build plugin twice, such as a javadoc-plugin configured to aggregate and a javadoc-plugin configuered per module. Maven 2.1 accepts the pom but seems to ignore the second, duplicate plugin. Duplicate entries are bad, you should instead configure multiple executions. Something should notify you though that it's skipping the second plugin declaration. I totally agree with you. Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoPJ88ACgkQmPuec2Dcv//+mgCbBgib7wgCTAAH1E+WBIct2BI7 X8cAn21Ir3cZfxSB+E4hhP+kW1Q4gG1x =GOo3 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Extending the Pom
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Shane, Something that I think would be useful is a language/platform element. Then it's purely additions to the POM. If you could identify the language/platform and it's version would that be enough for you? For this element, I think it would be better to have something more general. For example, I may want slightly different pom extensions for both Byldan and NMaven, both of which have the same platform. I do think, however, that also having a platform element within the pom is a good idea, as this would allow the artifact provider to specify target platform requirements for the artifact. This could then be matched against the Maven toolchain config, which would provide the build capabilities. I talked with Oleg yesterday about this and he said that we could define custom SAT rules for Mercury, allowing us to pull in different dependency chains, based on the toolchain/platform. Shane Do you know the concept that we Java guyz use for picking the correct platform specific dependency (e.g. when native code is involved). If you are interested, have a look here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=199302 Some link is broken but the attached POM is showing the idea. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoPLeAACgkQmPuec2Dcv/+rvgCeInXXB8PmS+fCPkSHT4rzNS3J hiYAoInA+/01uw81dttP4snGQN/qxAwq =Pyb1 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, OK. So you would NOT mind if maven adds some new features that are compatible to older versions of maven. Thats all I am fighting for. No fighting required, just make a patch. If it's truly backwards compatible, then there wouldn't be much reason for it to be declined. I'm interested in the use cases because during training I run into this a lot. Generally if you can move your process to one that works with Maven then it's not an issue. If you can't, well then it is. I've got ideas for how to make the release process better, but not enough time to tackle it now. Just updating the tools to support ASF policy is keeping me busy enough. I searched JIRA: It was already requested in MNG-2576 so it seems the idea and usecase is common and therefor good. The issue is closed/fixed but I could NOT get it working... Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNub8ACgkQmPuec2Dcv//RVQCgiqgQEvovdbDo+LHWBxbzOebn jUYAn0d4lIFFM1dTNa7A3dWeC1Q+OsgD =9QN4 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, By inheriting the version, groupId, etc. from the parent - yes. The release plugin still handles the pom transformations and the tagging (SCM URLs, snapshot to release version, release to next snapshot version, etc.) But there is nothing to change in the POM if the version is a variable. Maven will (as suggested in this thread - or also in my usecase via xslt-plugin) replace the variable when installing. All I need to change is one variable (e.g. in settings.xml). I do not need a releas-plugin for that but others may want to. I am also doing this in some other project that way and it works fine. But in my personal open-source project I have some core-libs that are used throughout the project and many modules that are piled up with lots of dependencies. I have some modules that are quite steady and do not change so I dont want to release a new version just because something else changed. I would try splitting those steady modules from the rest of the structure since they seem to not share a common development/release cycle. I would even consider moving these to another svn repository. Without a real example to analyze, hard to tell. Once again: the release-plugin guys think in a specific way and there are others that have a different oppinion. For me the architecture of the system is the main criteria for structuring my pom-tree. Imagine that everybody makes it the way you describe because of release-plugin. The other day another cool plugin arises that forces you to structure your poms and scm by some other criteria. What if you want both plugins? I think it is a bad idea that a plugin gives a philosophy about how users should structure their project. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNu1kACgkQmPuec2Dcv/8tqwCfTSDFbiyqVSbrKnwtSxqo7BK6 pJYAnjcjzGIwGrEvJ7PGhP8nZnsvT0+F =HnyW -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Stephen, If A(1.0) has root(1.2-SNAPSHOT) as a parent it should never have been released as the pom for A(1.0) is based on content from root(1.2-SNAPSHOT) which is subject to change... which means that a released pom does not have a definitive content... bad karma I agree and cant speak for Ralph, but I do NOT change versions (or anything else that is relevant for deploying) of container-modules at all. Why should I release a new version of my parent POMs if just some leave changed or even if some internal site-report-setting changed. People that want to use my deployed artifacts do NOT care about such changes. But in my case every developer always checks out the entire head (or tag/branch) of SCM. So there are different aspects of a deployed POM. If you ask me, all stuff like reporting, scm, issueManagement, distributionManagement, etc. is nuts for deployed POMs. But others may have a different view of the world. But this might be the point where we do not get together with relase-plugin. We simply have to accept that maven gives us flexibility to do things different ways and release-plugin maybe can NOT address all of these ways and thats just OK. -Stephen Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNxdIACgkQmPuec2Dcv/8SEgCgl/9Hnv5vfFAaRpz3noNdZuW1 x/IAn0AOXx3MSnC9xWvWFZKrZURU7OcR =aIQF -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Off topic. Actually I believe this isn't true anymore. See http://jira.codehaus.org/browse/MECLIPSE-344 all dependent artefacts that are available in your eclipse-workspace will be attached as project references even if they are not in the reactor. It was fixed in 2.5 Can you try it on your project structure and confirm? I know it works for me. I have this structure common projects - module cA ... - module cZ My project - module pA ... - module pZ (where some of these projects depend upon projects from commons) mvn eclipse:eclipse will make sure my module pA references the eclipse project for module cA (and not the jar of cA in the repo) Thanks for the hint! But only works if eclipse-plugin knows where my workspace is. The location may be different for each developer so I can NOT truly automate. Anyhow I will start using this. At least better solution than what I had before. Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNxrQACgkQmPuec2Dcv/8VrQCdGu/eWpZnifkPYdW/u+6RqsKx +eMAnRv5/EHXo0895onKGsmExxxtoC70 =gj/Z -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I think you are referring to one of the other patches that was submitted, not what I committed to the MNG-624 branch. MNG-624 or maven-2.1.x-MNG-624 ? A big problem could be the encoding issue if you store XML in a string and then want to save it with some Writer, you need to know the encoding from the XML-header or you run into trouble. My fix didn't store the XML in a string, it modified the DOM. OK. But the existing parsing is done by XPP right? Do we want parsing the POMs twice with different parsers? Is there some general strategy decision about POM-transformation design by the core developers of maven? Do Brett and Jason care about this? Sorry for the stupid question, but your patch/branch seems to be the second solution so this means to me that the first has failed already. I now see that is was Eric Brown who wasted his time already and he seemed somewhat disappointed. As the problem of doing a POM-transformation which is NOT only relevant for MNG-624 is quite general. So I just want to avoid that the second approach will fail again. I would not mind to invest some of my very little time as well in this but only if there is a clear chance that we are going towards a solution that fits well into the architecture of maven and will therefore be accepted to be integrated in 2.1.x. Ralph Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoNzB8ACgkQmPuec2Dcv/8d0wCfcKw58DuETsqdU8vZfHPJEZ66 vXIAn3QzreDl/1scgqpAPlDMu62OP4Ku =xUpi -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven and maintaining version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, After I got lost in the thread Progress on support for large projects and opened MNG-4161, I started to collect everything that is going on in JIRA about this. I added this to MNG-4161 but also wanted to point this out here: * MNG-624 - automatic parent versioning * MNG-2412 - global variable filtering of pom.xml for parent and sub module pom.xml files is not working when deploying to a repository. * MNG-2446 - parent Pom properties not resolved for module dependencies * MNG-2971 - Variables are not replaced into installed pom file * MNG-3057 - properties not expanded in generated POMs when building A/B/C nested projects * MNG-3782 - [regression] Variable substition not performed in transitive dependency using value from active profile * MNG-4161 - possibility to omit version in dependency of same project (and fill in on install/deploy) * MARTIFACT-32 - Maven does not expand expressions while installing artifacts locally * MINSTALL-50 - provide property filtering on .pom files placed in local repo Quite impressive list. So there seems to be a high demand in this topic. Maybe we should bring some things together. Take care Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoN0Z8ACgkQmPuec2Dcv/8mDwCdFy4uCjoxDVf7CWyQVhYUCeRw xwYAnREHSE6L2ApaUVDqshHbPXO74sb6 =bDbL -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Brian, Your better bet will be to try and get this documented so it can be implemented in 3.x. I would surely NOT mind. What do you expect? A new xdoc? Or a diff to the actual source of http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html Content somewhat like the level of detail in MNG-4161 but with nice examples? Do you need simple IT-projects that I shall attach to MNG-4161 and related? Best regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoN0p4ACgkQmPuec2Dcv/8TnwCfRZXQ8Wz1OOMwq4B8MXKanWyo 4qUAn0vYofuQCDUjS+PjOQ46VvgfpUUN =GiG2 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again, Your better bet will be to try and get this documented so it can be implemented in 3.x. no change to see some improvement about version maintenance in 2.x? See the list of issues I just posted and also look at the votes. Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoN0zkACgkQmPuec2Dcv/+QagCgiQd4XEKgBWh4c98TkflW3Bek 2GcAnRdoBJSi3wWoLHEA6jJB3N8pvSAr =l02j -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Chistian, What stops a developer from making changes to A(1.0) on trunk, rebuilding locally - that is - overwriting release artifacts with something different in the local repository, and then later on even commit those changes forgetting to increase the version to a snapshot ? Discipline ? Simply at a pre-commit hook that only allows to commit pom.xml in some tree that has a non-snapshot version. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoMj8AACgkQmPuec2Dcv/+KugCgiacqSwnZayMjGJa8ZxT05Gtt zJ8Ani67Nf5LSK8u9dww8XpDaFcSepN9 =kKR3 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Christian, My question may have sounded rhetorically but I really meant that. You could of course manage commit rights with subversion so that whenever someone mistakenly would try to commit to that release version on trunk, subversion could simply disallow that. So a developer would at least have to ask someone for permission to do so. I just don't get the point for what all this additional effort is good for. Really only to not release artifacts whose code did not change ? As I see it, that only introduces additional complexity without any advantage. I totally disagree. If your project is large and maybe offers components that will be used by others, you can get into version conflicts and will cause a lot of overhead in the repos. Anyways if you say it is just additional complexity and you should always release everything, then why do you have individual versions per module at all? Simply use one variable in every module and your process is so simple that there is no need for release-plugin anymore at all. I am also doing this in some other project that way and it works fine. But in my personal open-source project I have some core-libs that are used throughout the project and many modules that are piled up with lots of dependencies. I have some modules that are quite steady and do not change so I dont want to release a new version just because something else changed. Indeed it introduces some disadvantages every developer must be made aware of and you cannot use quite well working maven tooling that way. Not because this tooling behaves wrong, IMHO. The same applies to automatically discovering the parent pom. That's constantly changing artifacts without anyone noticing it, somehow. At least in all local repositories. It does not matter if there are any code changes. Changing poms is the same as changing code, IMHO. I would just say that it takes less than a week until every developer has its own releases in the local repository and noticing that is really not that easy. For me such setup would not work at all since the CI server not only builds artifacts whenever someone committed something, but forcibly runs builds every few days or so. So for me that would just mean that the CI server would constantly deploy differing release artifacts. Even worse, those release artifacts contain a reference to a snapshot parent pom which introduces additional problems. Non-reproducible. Why? In SCM there should never be a non-snapshot module with snapshot dependencies. Further a non-snapshot module should not be modified except for pom.xml Don't get me wrong. I still think you have really good reasons for doing things the way they are done. I just don't get it. I don't even see a single advantage but a lot of disadvantages. I am not saying that there may not be any advantages. OK. So you would NOT mind if maven adds some new features that are compatible to older versions of maven. Thats all I am fighting for. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoMkq4ACgkQmPuec2Dcv/9CxgCfXlKe4c7C0QtVPKY1kW4iUzQH IZ0AoJA//ENI/jHk000ELe3oN73g5nyW =zvjI -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi David, [cut.] Sorry I wasn't more specific last night at 2:00 am :-). I need more scm context to understand. I'm assuming something like svn with +tags +root-1.0 (1.0) +A(1.0) \B(1.0) +root-1.1 (1.1) +A(1.0) \B(1.1) \root-1.2 (1.1) +A(1.0) \B(1.2) \trunk \root(1.2-SNAPSHOT) +A( 1.0? 1.0-SNAPSHOT?? 1.1-SNAPSHOT???) \B(1.3-SNAPSHOT) I have several assumptions about releasing stuff... - development will continue after the release - therefore the version in trunk must be incremented so it's clear that snapshots are later than the release - tags should not contain anything with a snapshot version - releasing will create a tag of what's been released - tagging for release creates a copy of an entire svn subtree, not a copy with stuff removed. I see several problems with the svn tree I sketched above: - there are 3 or 4 copies of A claiming to be version 1.0 - there is no plausible version for trunk/root/A - in tags, the version of root doesn't match the end of the directory name. (there are 2 version 1.1 roots) I must not be understanding something basic about what you are proposing I'm probably beating a long-dead horse but could you please be even more specific about what scm operations you want to have as part of a release and what the scm repo looks like afterwards? Like Ralph, I have no problem with my scm (which is indeed svn). I also want to maintain versions of modules and have the problems that when I change a version I typically have to change this in all other POMs pointing to the module that changed version. Besiders there can be excuses where a dependency version remains unchanged, so no automatism that release-plugin could guess. And I want to keep modules unchanged in the tree. In my case they would NOT have to be rebuild but that does NOT matter to me. Maintaining these redundant versions is hell if you do it by hand. I have some hacky tools but it could be so easy if you could just omit the version in the dependencies of my local pom.xml's. To answer the SCM-structure question: There maybe some good conventions but SVN gives you a lot of flexibility in whatever you do. I personally always have a flat list of all my modules in tags and then have the according module copied (tagged) there named by its version. I never think that release-plugin has to deal with all possible ways that users can do their release-management. It has to go some way and there will always be people that want it different so I think the release-plugin is NOT the magic answer to all of our problems. thanks david jencks Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoLGWUACgkQmPuec2Dcv/9MggCbBGoMTwZOct1/WiOBUjPmUoxa SQYAn2+uQ6MPAWWSSuUPyX9oK0wtr9hV =YdFZ -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Milos, mvn eclipse:eclipse does perform a build (partially) and might even produce 1 eclipse project for multiple maven projects (correct me if I'm wrong) No it does not. But I hope it will one finest day. And it will definitely do NOT compile or invoke tests. All it does is invoking phases for code-generation. In NetBeans (IDE I use and develop maven integration for) no build is performed and we rely entirely on maven metadata when it comes to project representation. Doing a build is out of questions, opening of projects would be too slow. And it's a perfectly sound to assume that one wants to open just a single maven project from apache geronimo codebase without actually building the 200+ multiproject. I am absolutely with you that you do NOT want to build entire geronimo if just one module changes. What I was thinking about is that if mvn somegoal is invoked in module some-module maven scans the pom.xml of some-module. Currently it resolves all parents up to toplevel starting from some-module. What it does NOT do is to go down from toplevel and scan (NOT build!) recursively the entire project tree so all modules are available to maven's internals (that what I named the reactor) but that does NOT mean, that the goal is invoked on all of the modules but still only on some-module. But now the invoked plugins could resolve what other-module in the tree is about. I was suggesting to have this feature disabled by default but have a command-line option to enable this. Ask someone why you have to invoke eclipse:eclipse on toplevel everytime. If the dependency of some-module has changed, you can NOT invoke eclipse:eclipse just on some-module since the plugin then wants to resolve the dependencies from the repository and adds JAR-Dependencies to the IDE project. Further ask someone why you can not build some-module if it depends on other-module but thats not already installed. It can be on the local disc and the knowledge how to build some-module is available to maven but it is simply too stupid to do it. You have to go and invoke install on other-module yourself and then on some-module afterwards. Now try to explain this to somebody new to maven. Next there might be some tests that fail in other-module so you cant install it but still want to build some-module. Even with brutal performance hacks the 200 projects take about 10 minutes to open, while the single project is just a snap. Surely. I'm not sure what the auto-reactor feature in eclipse does, Maybe my post was missleading, but I was talking about a vision not about what already works. but in general and especially for large projects it's hard to figure automatically what the reactor is.. is it just the geronomo plugins pom, or we need all of geronimo, or just geronimo aspectj plugin parent? if you are the geronimo dev you might know, but will everyone figure that out? Well let me say so. I am suggesting a new feature to maven that is 100% downward compatible. Nobody has to use it if he does NOT like it. But it would solve the problems of many users and make maven even better. Milos Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoLHgoACgkQmPuec2Dcv/+L0gCZAfkMoCLgf8608h4vKxmGka7C F0MAnRoehAtfciJHGFSFdyQLDI/cWCyi =CpO/ -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ralph, I've been promised by Jason that the work on Maven 3 is going to fix some of these issues. I simply haven't had the time to look at the work on Maven 3 and even if I had, it has been changing at a fairly rapid pace for months. While, in principal, Maven's processing is pretty simple - it just collects artifacts and runs plugins - the reality is that there are lots of side effects and timing issues. OK. The fix needed to address 2 things; determining the parent pom version and resolving variables so that when the pom is deployed to the repository the pom isn't ambiguous. That does not include resolving variables in dependencies because those are actually OK to not be locked down in the repo. Unfortunately, once the pom is processed it is impossible to use the Maven Model object to create a new pom. It contains lots of information that wasn't in the original pom that shouldn't be in the pom deployed to a repository. The fix I did took care of this effectively. Writing it to an alternate directory and then telling maven where it was meant that the artifact deployer didn't need any changes at all. Okay. So thats what I guessed when I said that the MavenProject/Model is just a stupid POJO and various plugins manipulate it with side effects. Sounds a little hacky to me but thats the way it is. So my serialization idea is nuts though. Anyhow I think that if you have some information in memory, you should NOT have to write it to the disc so that someone else can copy (read and write) it again. I thought that you store the transformed XML in that new string attribute (was it alternativeRepresentation) so the Installer/Deployer could write this string if available instead of copying the pom.xml as is. A big problem could be the encoding issue if you store XML in a string and then want to save it with some Writer, you need to know the encoding from the XML-header or you run into trouble. Ralph Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoLIHwACgkQmPuec2Dcv//OawCfTCpa29oxzE68SoadDl2pYOC2 uAsAn1/+M2rOHg+UlrklPJRabJD7oK6s =YnIP -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Brian, Are you using the release plugin? Nope! I tried it and came to the point that is no good for me. I also had a discussion with the developers long time ago and filed some feature request. Anyhow I still think this is the wrong approach for me. Can you give more details about what doesn't work or doesn't match your process? E.g. it tried to convince me to release all modules of my entire project and complained if some module had a non SNAPSHOT version. [cut.] The new reactor modes are in 2.1.0 that can do some similar things. [cut.] Some of this is already done in 2.1.0 Great to hear that. Please give me some hint (weblink, example or whatever) to get started with this. Best regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoJ4coACgkQmPuec2Dcv//ZqACgkQiOIFbclxDb1A/cZr1JjyiX P4IAn2OiW+XcJizxnzYmmXRzsusBx/7n =AinT -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Milos, relying on the reactor and giving up on being able to build the one project separately is very bad (read: completely breaks) any IDE integration. I totally disagree. I am successfully using maven-eclipse-plugin (mvn eclipse:eclipse) and this works perfectly with Eclipse except if you do a lot of filtering. The suggested approach would have no influence on my IDE, omitted versions would become inter-project-dependencies in eclipse and everything is fine. I tried m2eclipse and iam about 20 times and always gave up, because they were simply NOT able to run my project. E.g. I have source/target set to 1.5 for compiler-plugin but require 1.6 for development. m2eclipse thinks that it needs to replace 1.6 with 1.5 wenn I do m2 enable of my project. However if all the bugs of these plugins would be fixed, and the auto-reactor feature was working, everything could be fine as well together with the suggested feature. One day there will be eclipse 4.x and support multi-projects so the entire project (and its reactor) can be managed as a whole. I heard this already works for idea. Milos Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoJ47EACgkQmPuec2Dcv//5iACfc1jnc4F33uoOKQ/JFKO8IUuP x5sAn2m0GO5n32Uz+r0C1Fa23x1PjXxx =zmBx -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ralph, Hi there, absolutely everybody having large maven projects is annoyed by maintaining the versions in all the poms. Are you using the release plugin? This problem probably goes away for anyone able to use the release plugin, but only because the release plugin does all the work, not because the need for the work goes away. If, for whatever reason, you can't use the release plugin, then this is a real pain. Yep, I am having this pain and I now dozens of others that have the same problems. Additionally the complete solution is quite simple and seems to be quite common sense: 1. Allow to omitt versions in parent as well as in dependency that is available in the reactor. Omitting the parent is complicated. Ralph started an implementation but we found some issues with it at ApacheCon. I don't think it's gotten beyond that yet. Actually, the guys I work with started to complain about this again last week and want me to fix it. They suggested that rather than tackling both accepting a missing parent version and fixing the pom so that the pom written to the repository is fully resolved (i.e. the parent version is present in the deployed pom) that just accepting the missing parent would be enough. I'm not sure, but I'd be willing to look at it. I'm also not sure how much things have changed since I created the branch. I'll have to check. I have read your comments. Well thanks so far for all your work and invest. I hope you have NOT lost your faith ;) The only real problem with what was on the MNG-624 branch was that it requires a place to create the resolved pom.xml. To do that it assumed a hardcoded location of target. If a parent pom redefines the build directory (it seems really odd to me that this is even allowed) then this is wrong. But trying to find the definition of the target variable requires looking at every parent, even if it isn't local, which is something I was trying to avoid. I did not yet get the point, why you have to write a new pom.xml to the disc. My naive illusion was that there is a central component that reads and parses the POM in maven where you can hook into and perform the transformation. Then all additional work is to assure, that plugins such as the install plugin do NOT simply copy the pom.xml to the local repo but include the transformation. Here we might run into the problem that the POM XML is de-serialized with a parser (was it XPP or is it StAX) and the internal representation looses information so it can NOT be serialized again without loosing indentation, comments, etc. of the original pom.xml. Anyone is free to look at the branch and improve on it. You can use dependency management or properties to deal with omitting the dependencies. I personally never assume what will be contained in a reactor and structure my builds so that any module can always be built in isolation. Therefore, I can't see why you would want to omit the dependency for something in a reactor that may not be in the reactor all the time. The release plugin handles this for you when it's time to bump the versions. 2. Ensure that omitted version as well as variables in groupId artifactId and version are replaced when a pom is installed in the repository. Agree with this. Yes, the fix in MNG-624 does a really good job of this. So your patch also resolves variables and NOT only in parent but also in dependencies-section? Havent seen that... However I totally lost where we are and what is going on. http://jira.codehaus.org/browse/MNG-624 http://jira.codehaus.org/browse/MNG-2971 http://jira.codehaus.org/browse/MNG-3267 http://jira.codehaus.org/browse/MNG-2971 I could not find the one to omitt version in depdency. Can anybody remember. Or do I have to open a new one. I can not really tell how hard it is to make this work, but be sure that we can make millions of users happy with this! Where we are in this is that I have been totally booked writing code for other projects - mostly commons VFS and commons configuration. I have the same problem. The main reason why I am here is because I am using maven in all my other OSS-projects and I love it but sometimes I also hate it and hope that the tiny parts that are not already perfect will go away some day... As Brian mentioned, he and I discussed this at the last ApacheCon US and found the issue noted above. I simply have not had the time to figure out how to solve that. Even if you can't contribute a patch a really good idea would be welcomed. I will try to give it a little dive - but I have NOT done much other than some MOJO-coding so far and sometimes get lost with mercury, plexus, wagon, etc. and I have just little time. Still looking for someone who likes to pay me for doing OOS development ;) Ralph Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Fox wrote: Can you give more details about what doesn't work or doesn't match your process? E.g. it tried to convince me to release all modules of my entire project and complained if some module had a non SNAPSHOT version. Since it's going to convert a module to a release version, you shouldn't have to convert them by hand first and thus they would always be snapshots in scm. It's true that it will want to release the tree from where ever you run it, but that can be mitigated by constructing trees that match how you do releases. As I already said, I talked about release-plugin and my view of the world and it seems NOT to fit together. My POM-tree follows strict logical aspects that is motivated by the architecture of the project and NOT by the philosophy of some plugin. Thanks anyways for your advice Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoJ7N4ACgkQmPuec2Dcv//5uQCfXQVEGdOCjcCNZp+uMiDUvaFk MV4AnRewsPtcFh9npnlsvuByNSmxmypN =tQlc -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again, I did not yet get the point, why you have to write a new pom.xml to the disc. My naive illusion was that there is a central component that reads and parses the POM in maven where you can hook into and perform the transformation. Then all additional work is to assure, that plugins such as the install plugin do NOT simply copy the pom.xml to the local repo but include the transformation. Here we might run into the problem that the POM XML is de-serialized with a parser (was it XPP or is it StAX) and the internal representation looses information so it can NOT be serialized again without loosing indentation, comments, etc. of the original pom.xml. I read your patch and started to get some parts of the puzzle. 1. The component that reads and parses the POMs is the MavenProjectBuilder. So it is generally possible to do the transformation there. 2. Installing and deploying is NOT diretly done in the according plugins, but in ArtifactInstaller/ArtifactDeployer. Wise decision of the maven designers so we do NOT have to touch all MOJOs that deal with this. Still I do NOT know if these plugins need some dependency-update to see such change or if they just depend on the according API and the implementation (DefaultArtifact*) comes with the artifact-version of maven itself. So maybe my idea is right that for the long run maven developers should think about being able to have a 1:1 (de)serialization possibility from pom.xml to MavenProject and vice versa. This way one could make transformations on the POM and ArtifactInstaller/ArtifactDeployer will serialize the project to XML instead of copying. But are there some MOJO-hacks out there that also manipulate the MavenProject and would cause to modify POMs accidently on install/deploy? Or is it NOT possible for regular MOJO to change the MavenProject. As far as I see it is just a plain POJO but it could be proxied or whatever. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoJ8dIACgkQmPuec2Dcv/9dcACeL7SEqDxSwuBJMUETpfFEEsRt 3VUAnApJkG7mPAYfF1ADSBslgP1k6lGk =NAWp -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Brian, As I already said, I talked about release-plugin and my view of the world and it seems NOT to fit together. My POM-tree follows strict logical aspects that is motivated by the architecture of the project and NOT by the philosophy of some plugin. I'm trying to understand your structure and motivations behind it, so if you would care to elaborate, we can be sure to consider these aspects down the road. Sorry, maybe my words were a little rude (thanks christian btw). I am also NOT a native speaker... Thanks for your friendly response though :) My idea of release-plugin was that if a module in the tree (reactor) has no snapshot version, it should NOT be released then. This allows me to open individual snapshots of single modules without versioning the entire tree (including modules that have NOT changed at all). But how would I tell release-plugin to open one module for development as snapshot and update all other snapshot modules that depend on it so they point on the proper version. I started thinking about a swing GUI opened by the plugin that shows the module tree and allows to change versions including dependencies on that and shows modules that point to an older version of a reactor module. Whenever I thought about it, I came to the point that the problem is just that you have to change versions redundant in various POMs. So if you could just omit the version in case you want to express that you mean the version from the reactor that is in latest state on your disc and in your IDE, all problems were solved. But as pointed out, when the POM is installed/deployed, you have to insert the version valid at this time. It is already possible if you define the versions all in toplevel pom, set all versions of modules with packaging pom to 1.0 and never change them semantically in dependency and build sections and finally add some XSLT MOJO bound to install phase that transforms the installed pom replacing the version. A hack so far, but my hope is that it will work smooth one day with plain native maven standard. Thanks again Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoJ9oAACgkQmPuec2Dcv/8c5gCgmYPuA1K7Wg32nvFpFLlemoWr oAIAnRmVKP801i71yysAVDen9b+BlK0P =UIdK -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, thanks for your answer... absolutely everybody having large maven projects is annoyed by maintaining the versions in all the poms. Are you using the release plugin? Nope! I tried it and came to the point that is no good for me. I also had a discussion with the developers long time ago and filed some feature request. Anyhow I still think this is the wrong approach for me. Additionally the complete solution is quite simple and seems to be quite common sense: 1. Allow to omitt versions in parent as well as in dependency that is available in the reactor. Omitting the parent is complicated. Ralph started an implementation but we found some issues with it at ApacheCon. I don't think it's gotten beyond that yet. I have read parts of this. I hope there is a chance to see this in the future. You can use dependency management or properties to deal with omitting the dependencies. I personally never assume what will be contained in a reactor and structure my builds so that any module can always be built in isolation. Therefore, I can't see why you would want to omit the dependency for something in a reactor that may not be in the reactor all the time. The release plugin handles this for you when it's time to bump the versions. I see your point. But I am always building from toplevel. Anyhow I am also dreaming of a cmd-option in maven 3 that enables a mode where maven walks up to the loplevel pom (as far as locally available) and creates the entire reactor while still building just the module where it was invoked. This could solve the problem you pointed out as well as many other problems, e.g. to do dependent builds of local modules. Anyhow this would just be a feature that does not hurt and would not cause downward compatibility problems if assured, that install/deploy will fill in the omitted version. 2. Ensure that omitted version as well as variables in groupId artifactId and version are replaced when a pom is installed in the repository. Agree with this. Great. So I hope for MNG-2971. Anybody out there can let me know if this is just waiting for contribution. I might work on this one if it is just about that feature in the install-plugin. If there is some more general architectural change needed in order to make this also work with release-plugin and many others let me know - I might not see all possible problems. I think I also read some ideas about POM-Transformation in maven 3... However I totally lost where we are and what is going on. http://jira.codehaus.org/browse/MNG-624 http://jira.codehaus.org/browse/MNG-2971 http://jira.codehaus.org/browse/MNG-3267 http://jira.codehaus.org/browse/MNG-2971 I could not find the one to omitt version in depdency. Can anybody remember. Or do I have to open a new one. I can not really tell how hard it is to make this work, but be sure that we can make millions of users happy with this! Thanks Jörg Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoG0h4ACgkQmPuec2Dcv/8zqgCghlevEs/YlVRLaaTIWQl6yi5W kJYAn00C5R0sjXjIl6Z08EtMCFEFIMHN =yhX0 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven 2.1 incompatibility list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I found that there is a little list of incompatibilities form m2.1 at: http://maven.apache.org/release-notes.html However there are a lot more. E.g. with maven 2.0.x you could have a module included in your toplevel pom that you also add as dependency to some plugin such as checkstyle or findbugs. In maven 2.1 you have to remove the module declaration or you will get a cyclic dependency error (that is hard to unserstand since it says that some module depends on itself - which is right but you can not see this in its pom directly because it is inherited). Additionally with maven 2.0.x you could have the same build plugin twice, such as a javadoc-plugin configured to aggregate and a javadoc-plugin configuered per module. Maven 2.1 accepts the pom but seems to ignore the second, duplicate plugin. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoF7CgACgkQmPuec2Dcv/95EgCePZW6Cd/dC8R9adyPtK6o89Xf FRUAnj9Q6GgeeIi1LVBe1kq1Kx8BrE6w =WgUV -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Progress on support for large projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, absolutely everybody having large maven projects is annoyed by maintaining the versions in all the poms. Additionally the complete solution is quite simple and seems to be quite common sense: 1. Allow to omitt versions in parent as well as in dependency that is available in the reactor. 2. Ensure that omitted version as well as variables in groupId artifactId and version are replaced when a pom is installed in the repository. However I totally lost where we are and what is going on. http://jira.codehaus.org/browse/MNG-624 http://jira.codehaus.org/browse/MNG-2971 http://jira.codehaus.org/browse/MNG-3267 http://jira.codehaus.org/browse/MNG-2971 I could not find the one to omitt version in depdency. Can anybody remember. Or do I have to open a new one. I can not really tell how hard it is to make this work, but be sure that we can make millions of users happy with this! Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoF+UIACgkQmPuec2Dcv//gDACfRvtIJ+CrTatgMZiynQ/2/f7+ 7DQAni6uH3UkGSU0WNFKuUCz5OsyrGy3 =Jn88 -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Filtering component
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
so far so good.
I have the following suggestions:
1. Also specify that the pom.filters are
in the order of their declaration in
the XML.
They are not used (as they are not used in resources plugin 2.2 and
adding filters as a child of the project element is not valid).
Are you talking about the fact, that I wrote pom.filters.
I thought everybody would understand what I am talking about.
But yes you are right, it is
pom.xml/project/build/filters
Anyhow I still want to say that the order of the declaration
should be honored by maven!
2. Resolve variables whenever they are requested.
What I mean is that I can do
filter1.properties:
var1=Foo
var3=${var2}/Thing
filter2.properties:
var2=${var1}-Bar
So if I resolve ${var3} I get Foo-Bar/Thing.
That would be an excellent feature, since I am using
maven for deploying a large system and therefore
build it as multiple debian-packages with
seperation of application- and configuration-packages.
The configuration packages are build for
production as well as for 14 different
testing-environments. Various ports, hostnames, etc.
slightly differ in these environments. I could avoid
a lot of redundancies and daramtically simplify my
filters with the features described above.
Do I need to file a JIRA ticket or is this enough
input?
No because it already works (there is an it[1] for
this in the resources plugin).
It seems to me you are a bit too quick with your
conclusions.
Maybe that your integration-test works. But the
feature I am talking about does NOT work.
See example:
pom.xml:
?xml version=1.0 encoding=UTF-8?
!-- $Id: pom.xml 566 2008-07-25 19:51:37Z hohwille $ --
project
modelVersion4.0.0/modelVersion
groupIdfoo.bar/groupId
artifactIdtest/artifactId
version1.0/version
packagingjar/packaging
nametest/name
descriptionfiltering test/description
build
resources
resource
directorysrc/main/resources/directory
filteringtrue/filtering
/resource
/resources
filters
filtersrc/main/filters/filter1.properties/filter
filtersrc/main/filters/filter2.properties/filter
/filters
/build
/project
src/main/filters/filter1.properties:
var1=Foo
var3=${var2}/Thing
src/main/filters/filter2.properties:
var2=${var1}-Bar
src/main/resources/test.properties:
var1=${var1}
var2=${var2}
var3=${var3}
now do mvn process-resources
and you get
target/classes/test.properties:
var1=Foo
var2=${var1}-Bar
var3=${var2}/Thing
What I am expecting is:
var1=Foo
var2=Foo-Bar
var3=Foo-Bar/Thing
Thanks,
--
Olivier
Take care
Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFI69bEmPuec2Dcv/8RAibJAJ4wIEpNy9K2hRfnBFOfbWQ3LBFL2gCfe9JO
b+6+DF8VRWampqo0xTPfFjA=
=HIjj
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Filtering component
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Hi there,
as often I a little late on some threads ;)
I have start a proposal [1]
so far so good.
I have the following suggestions:
1. Also specify that the pom.filters are in the order of their declaration in
the XML.
2. Resolve variables whenever they are requested.
What I mean is that I can do
filter1.properties:
var1=Foo
var3=${var2}/Thing
filter2.properties:
var2=${var1}-Bar
So if I resolve ${var3} I get Foo-Bar/Thing.
That would be an excellent feature, since I am using
maven for deploying a large system and therefore
build it as multiple debian-packages with
seperation of application- and configuration-packages.
The configuration packages are build for
production as well as for 14 different
testing-environments. Various ports, hostnames, etc.
slightly differ in these environments. I could avoid
a lot of redundancies and daramtically simplify my
filters with the features described above.
Do I need to file a JIRA ticket or is this enough
input?
My suggestion to implement this, would be to
create chains of Properties that inherit
from their parent and resolve this in
getProperty(). However you might not want to
use your own API defined as clean interface
instead of Properties.
Thanks
Jörg
Thanks for comments,
--
Olivier
[1]
http://docs.codehaus.org/display/MAVEN/Resources+Handling+(common+component+maven-filtering)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFI2pjzmPuec2Dcv/8RAj+JAJ9CuWvkh8A+UbHxgJfksaIPQbT5hQCfete7
XejVhEEoWmQxfpIvgoLLJJ4=
=xaPy
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: XBean and DI?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, The additions Dain has made to XBean adds things I was just never interested in like constructor injection and bean factories. Also xbean-reflect thinks in java.lang.reflect.Type terms so it's easy to add converters that are generics-aware. For example I recently added converters for MapK,V and SetT and ListT and it only took an hour. I spent the last year with creating support for this. You have to rebuild all the stuff that is in javac but missing in the JDK. The erasure was maybe the only way to introduce generics but it is a real pain. I almost got braindead with this. Is ? super CharSequence.isAssignableFrom(? super String) or vice versa? Could not find the time to have a look at XBean but I doubt its doing the stuff right with java.lang.reflect.Type. Please let me know if I am wrong. Write some class Foo extends ListString and then BarE extends Foo further Some extends BarInteger. Now let me know if XBean tells you that Some.get(int) has the return-type String. My implementation does... Maybe you want to have a look. However still in progress of improving, so you might NOT want to use it now... https://m-m-m.svn.sourceforge.net/svnroot/m-m-m/trunk/mmm-util/mmm-util-core/src/main/java/net/sf/mmm/util/reflect/api/GenericType.java Site has NOT be updated for a while but also http://m-m-m.sourceforge.net/maven/mmm-util/mmm-util-core/index.html http://m-m-m.sourceforge.net/maven/mmm-util/mmm-util-pojo/index.html Just in general the code is pretty small and tight as well and generally very easy to add features. -David Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI2p5PmPuec2Dcv/8RApPgAJ9n5f9eeNVBVukFTx6vFThacyI/0gCcDPyw tNxIS2JZbqwtmcV8JkZCV2A= =3ikU -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modifying Version Number in POM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
| In POM we have a version number of the project as
|
| version1.4/version
|
| Instead of hardcoding it each time I take a new build, I would like to
| replace it with the one entered by the user when he takes a buld using
| maven. I want the user to enter the version number, which will be used
| placed in maven's pom.xml and then used by Maven. So this is like modifying
| the pom dynamically.
You may use a variable like this:
version${my.project.version}/version
Then call maven like this:
mvn install -Dmy.project.version=1.4
|
| I was thinking to call a ant task (which in turn calls a shell script asking
| for the user to enter the version number) from within the pom when the user
| executes the *mvn install* command.
|
| Is all this possible with the approach above? How do I call a ant task that
| runs BEFORE maven proceeds for all other stuff.
| Similar to a constructor that is executed when you create a java object, i
| want this task to be run.
|
| Please help.
|
Regards
~ Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIW18xmPuec2Dcv/8RAi2QAJ0QxLZplME5daLJM1/3195bv53/GgCfbzSu
T3Pe2NgjcSTRP8oRmbp6V7w=
=y45h
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: An Attribute Based POM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, just to give my feedback on the thread: +1 for NOT overloading 2.1 When it is about further versions and long term future of maven: - -infinity for artifact=org.apache.maven:maven-project:2.0.8 How do you want to express versions ranges then? Mix it all together? With XML it is possible to still understand the content even if a new attribute or element has been added that you do not know yet. when you have colon separated lists this is NOT possible. Further the unfamiliar reader has NO idea what the of the n.th segment is cause it is NOT named. He might not even know if the separator is . or :. If you see groupId=foo you can google for groupId and you might find what you are looking for. +1 for more readable POMs I personally like the idea of the attributes because it makes it a lot easier to write the POMs, cause you do not have to open and tag close a tag /tag and may end in groupIdfoo/artifactId copy and paste mistakes. However when I scanned the big example http://svn.apache.org/viewvc/maven/archiva/trunk/pom-4.1.0.xml?content-type=text%2Fplainview=co I did not get the impression, that it is really easier to read, since your eyes get overdosed by the dominating pattern dependency groupId=org.apache.maven.archiva artifactId= so you miss the important things even though it is more compact. +1 for dependency ... excludeAll/ /dependency but for the very long run. I think there are more such feature requests, that users would love to see. Simple have a look at the exclude and include parameters of the dependency-plugin. However it would still be possible for the install/deployment to transform the excludeAll/ to a maven 2.0.4 compatible syntax automatically - just calculate the transitive dependencies and generate individual excludes for it. File a JIRA wish ticket for it... But not for 2.1. Is there a smart way to make it possible to allow feature-compatible syntax changes by having a plugin so people with older versions but at least maven x.y (2.1) would NOT be lost? Best regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHveSYmPuec2Dcv/8RAku7AJ9ETwe1+d45tvGUjeEC5MKqJB9ivACeO9az z09KdsDNWX31DGI/NT25b30= =7A3v -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] MPLUGIN-40
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Finding the definitive help information for a plugin should be absolutely trivial and built-in; having the CLI option which give the code-you-are-executing-right-now the ability to answer that question avoids the issues we have today with multiple sources for a plugin with different HTML usage information. Have you tried mvn help:describe -Dplugin=nifty -Dmojo=nifty -Dfull? I think we already have what you want, but we've yet again failed to document it adequately. (Try it with -Dplugin=compiler -Dmojo=compile.) My point was useability; my first thought would not have been: mvn help:describe -Dplugin=nifty -Dmojo=nify -Dfull but something like: mvn nifty:help So, as you point out, all that would be needed is to hook up mvn plugin:help to mvn help:describe -Dplugin=plugin -Dmojo=all? -Dfull. Maybe we would need a more specific syntax in this case because some plugin might supply a help mojo and rewriting this as suggested and overruling an existing help-mojo would be quite confusing. But anyhow your suggestion is well worth a thought. I would prefer that if maven builds a plugin that has no goal help already, then it auto-generates one in about the same way as it does when generating the goal-documentation for the site. Then each plugin would have (in future versions) a help mojo and mvn plugin:help would work as expected. Additionally a plugin can provide an individual help goal that produces a more user-friendly hand-written help page. Third if mvn plugin:help is called and plugin points to a valid plugin that has no goal help then maven could rewrite this command as suggested via help:describe. And while I'm at it, and relatedly, whatever happened to -G to get me a list of all plugins??? I never used 1.x, but I don't think that makes sense any more. We could certainly provide a list of all valid lifecycle phases (and we should do so in the help plugin), since those are static and don't change. Yes! That would be terrific. And a list of the currently plugged in plugins for each lifecycle phase would be handy as well. http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html But as for finding plugins, it's better to search the Internet for that sort of thing, rather than trying to turn the Maven core into an Internet search engine for Maven plugins. (Similarly, wouldn't it be cool if you could use a simple Maven command-line switch to search for jars you could use in your project? Wait, no it wouldn't; that's what Google is for.) I understand your point, Dan. And while I agree somewhat with that, I like asking Eclipse to update and or search for new updates that are relevant to my version of Eclipse. I can use Google, and that's cool, but if Eclipse can help me filter all the irrelevant stuff that's even better - like, say, plugins which don't work on my version of the software. I do NOT agree with this. Eclise does NOT know by itself about external plugins. It can update them if they are registered but you still have to google to find a subversion plugin, checkstyle plugin, emma plugin, findbugs plugin, etc. Besides this mechanism of eclipse totaly sucks!!! Eclipse shows the Display-Names of available plugins from update sites. If you select one and it has a dependency, the technical name of the dependency is shown. Sometimes I get totally lost in how to find a combination that is valid to be installed. They could learn a lot from maven about dependency management. The placement and configuration somewhere in help is totally misplaced, etc. Not really a good example to point out if you ask me... And I might as well chuck in: why in the world do I need to do mvn nifty:nifty and not just mvn nifty? Because that way we don't have to guess whether you're trying to run a goal or a lifecycle phase. install is a great example. Do you just want to run the install:install goal, or did you want to run every lifecycle phase up through the install phase? I agree; there is an issue with the plugins which are named the same as the static set of life-cycles, and that's unfortunate. But how about you make an exception for those that are not...which is the vast majority, no? So, really mvn nifty just means run the nifty plugin's default goal, and mvn install just means run the install life-cycle I agree! We should NOT be to academic here. There will always be users that will not and even do not want to understand the details about the difference of the lifecycle and the plugin. Naive users just try mvn eclispe like mvn install and in both cases it is clear what the user really wants to do. If you type mvn plugin and plugin is no lifecycle phase, maven could behave as if the user typed mvn plugin:plugin. We would not even loose too much control about lifecycle names because plugin is either fully qualified or it points to org.apache.maven.plugins:maven-plugin-plugin or
Module-Overview-Plugin?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, it seems I get ignored with this toppic on all channels. I will try to create a JIRA issue, maybe that gets read one day... Regards Jörg Hello everybody, I posted to the users list but got no answer. Further I think of a deeper integration now so dev-list might make more sense... | Hi there, | | I just wonder if there is already a plugin for maven2 | that can generate a table with the links, names, and | descriptions of the child-modules of a project. | I remember that this was produced by the multi-site | in maven1. After thinking about it, it would make a lot more sense if the overview table would be available through a doxia-variable so one could inject this inside any xdoc or apt page. Any comments? | I might write such plugin at the mojo sandbox but | want to get sure, if this does NOT already exist. | | Does anybody know??? For the moment I helped myself this way: http://m-m-m.sourceforge.net/maven/overview.html It is nice and clickable. However not autogenerated :( Maybe even this could be possible somehow with graphviz or something... | | Thanks a lot. | Jörg Take care ~ Jörg - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHqM+smPuec2Dcv/8RApBhAJ9jXEu2GvGy/6wImZ16axocRDlGkgCggyVV 6ebPqYmLzCn2XhP9bLlrQa8= =Tndp -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Discuss] MPLUGIN-40
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again, I wrote: I would prefer that if maven builds a plugin that has no goal help already, then it auto-generates one in about the same way as it does when generating the goal-documentation for the site. Then each plugin would have (in future versions) a help mojo and mvn plugin:help would work as expected. Additionally a plugin can provide an individual help goal that produces a more user-friendly hand-written help page. Third if mvn plugin:help is called and plugin points to a valid plugin that has no goal help then maven could rewrite this command as suggested via help:describe. Maybe I should have read the thread properly from the beginning. My suggested improvement to plugin-plugin seems to be what has already been done to fix the problem for the long run. However the further suggestion might solve the problem now and could be kicked out in maven 3.x or whenever each plugin does have a help goal. The only thing is that it needs to be done in maven-core and can NOT be made available via a plugin release but only by a new maven version explicitly updated by the users. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHqM7mmPuec2Dcv/8RAi59AJ9LUAFdnnfH183QVPq0ic1jljvIGgCghpRa 2T0HEfVYe+/4/ggf01JfF2U= =bIDc -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please comment: 2.1 Lifecycle Features on MAVEN Confluence space
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, | Right...I guess it'd help to include the URL: | | http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning | | Thanks! I generally agree with what you are saying. You are pointing out common problems very well. The solutions sound promising but here some further comments... | some plugins may need to be omitted in rare cases, | but ideally would be configured in the parent POM | for the 95% of child modules that do need it. | Here, it would be simpler to allow the child POM | to direct Maven to omit that plugin execution for its own build. To underline this one: http://jira.codehaus.org/browse/MNG-3321 http://jira.codehaus.org/browse/MECLIPSE-271 http://jira.codehaus.org/browse/MSELENIUM-21 http://jira.codehaus.org/browse/MCHECKSTYLE-43 http://jira.codehaus.org/browse/MHIBERNATE-50 http://jira.codehaus.org/browse/CARGO-481 | As mentioned above, the concrete LifecycleBindings/MojoBinding | model classes - along with the BuildPlan derivative | used to inject direct invocations and forked | executions - provide an easy way to inspect and | manipulate the list of mojos that will execute | during a particular Maven build. However, this | is worth highlighting separately: where 2.0.x | provided an immutable and obscure LifecycleMapping | class collected by lifecycle-name into a | java.util.Map instance, contained as a private | member of the DefaultLifecycleExecutor, Maven 2.1 | will present a concrete, strict syntax and class | model that can be built, rendered, inspected, | and manipulated via documented APIs. I am not quite sure if I get it right. But one the one hand you are saying, that the BuildPlan should be calculated first and potentially viewed to the user (e.g. via -X) to make build transparent and deterministic. On the other hand you are saying that each plugin can access the BuildPlan via an API and make modifications. How do these two points go together? The modification of the BuildPlan might be a very cool generic feature but please consider to add an ultra fat warning to the javadocs NOT to do this if there are better ways. This should not open the gate for ugly hacks. Whenever there are ways to do something, they will be used by someone. You know why Java was so successful? Because it is so restrictive and easy (at least before java5). Beside I would be pleased if you could revisit these two issues in this context: http://jira.codehaus.org/browse/MNG-3377 http://jira.codehaus.org/browse/MNG-3322 Thanks a lot ~ Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHo42ZmPuec2Dcv/8RAs7OAKCQXhGKoMah+dKpBxbELs+VOe3mPQCgjQIO u10CCbiULT16/Q3z1Qdhvfs= =l1FM -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Is there already a Module-Overview-Plugin?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello everybody, I posted to the users list but got no answer. Further I think of a deeper integration now so dev-list might make more sense... | Hi there, | | I just wonder if there is already a plugin for maven2 | that can generate a table with the links, names, and | descriptions of the child-modules of a project. | I remember that this was produced by the multi-site | in maven1. After thinking about it, it would make a lot more sense if the overview table would be available through a doxia-variable so one could inject this inside any xdoc or apt page. Any comments? | I might write such plugin at the mojo sandbox but | want to get sure, if this does NOT already exist. | | Does anybody know??? For the moment I helped myself this way: http://m-m-m.sourceforge.net/maven/overview.html It is nice and clickable. However not autogenerated :( Maybe even this could be possible somehow with graphviz or something... | | Thanks a lot. | Jörg Take care ~ Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHo5BTmPuec2Dcv/8RAitCAJ9tH/lflnYMuF6/UtI7ggu4bBF3vQCeL10S +1AcvMRK+ZJIoZnsxBDroyM= =SO0K -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix missing POM files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, | Heh, so you are willing to trade build reproducibility (for all | projects linked to central repo) for care about the community? o.O | | Hrm, please put that on a vote before you do it! | | IF you are talking about putting up dummy (depsless, only GAV) POMs: | IMHO, by putting dummy poms (without dependency to not screw | existing builds), only ones with GAV, you do not provide any value to | community: OSS projects usually move fast, and will quickly switch to | newer (hopefully fixed) artifacts from central with correct POMs. And | the companies will... heh, they will use some advanced repo manager | to solve it ;D The content of such poms is no real value but it stops millions of totally useless requests towards ibiblio and produces longer builds and stupid warnings. So it is more a denial-of-service attack that should be stopped. Look at axis2 with all its dependencies! There is no newer version out and I have about 50-100 useless requests to missing poms per day. My project team has 10 developers so multiply this by ten. I am also using maven for my open-source project. Same result. As ibiblio if you can get a 404 statistic. When you change the version of one of your dependencies you always have to face the fact that transitive dependencies change. That has nothing to do wheter the earlier version had just a stupid GAV pom or not. Adding a pom with additional dependencies afterwards causes a change of transitive dependencies in projects that did not change anything. Please note that business projects need a config-management where deployment is audit-proof and rebuilding a release on an old tag should still have the same result as it had when the tag was created. As people describe there is a workaround to solve this issue for enterprises but if they dont why should we cause such trouble if there is no need to do so. Ahh - I read your posting again. You were not talking about dependencies in the later added poms but in the next version. So my last paragraph was not directly related to what you were saying... | | IF not, how would you be able to get authoritative data to fill in the | missing POMs? | | Thanks, | ~t~ | | On Jan 28, 2008 7:51 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: | if there's no pom uploaded then you can take 5 minutes of your time | and provide one. I try to do it for all the ones I use. It can be | because you care about the community or because you are selfish and | want your project to be reproducible ;) either way providing a pom | doesnt take that long | | Regards ~ Jörg | - | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] | | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHoOyLmPuec2Dcv/8RAjbqAJ4m22dFzvlNd248uJNICYhc7eUVNQCfWkO1 ZNrRQwYYbbD439sTOJahMM0= =4TsK -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: source of missing dependency unclear
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 | Hi Joerg, Hi John, (top-posting this time) thanks for your detailed response. I am very happy to hear that you care and take this serious. Further I will be one of the early adopters if 2.1-alpha is out. Maybe I will find the time to test an 2.1 integration build before... Thanks ~ Jörg | | I'm sorry to hear you're having such difficulty with maven and its | error-reporting. All I can offer by way of consolation right now is that | I've revamped error reporting pretty substantially over the past few | weeks. I started by analyzing all errors that hit the | MavenExecutionResponse (and are subsequently reported at the end of the | build by the CLI class in Maven), then tracing these back to their root | causes, or as nearly as I can do within the confines of maven itself | (not the plugin code, since this could come from anywhere). In each | case, I've tried to give the user an error message with the details that | will help him solve the issue. I'm sure it's not perfect, but it's got a | much stronger test suite behind it, which goes to great lengths to | reproduce each error condition in a live test-project build. The new | error-message formatter also has a stubbed class that will allow us to | provide links to various documentation sites for hints on solving that | particular problem...these need to be fleshed out, but some of the basic | problems have links to documentation out on maven.apache.org currently. | | All of this is in Maven's trunk in Subversion, which is the branch where | we're pushing toward a 2.1-alpha-1 release sometime this quarter | hopefully (unless something comes up to derail the remaining work slated | for that release, of course). | | As for warnings and other things that happen in mojos but aren't thrown | as exceptions, it's an interesting idea to provide a recording Log | instance to the mojo, that would allow maven's core reporting | infrastructure to reproduce those warnings (in addition to errors and | other non-exception output above the INFO log-level) in the build | results at the end. I'd be a little concerned about making that output | noisy and obscuring the error-formatting work described above, but I'm | sure we can find a way to strike a balance there in most cases. | | I'm filing this idea under MNG-3381 | (http://jira.codehaus.org/browse/MNG-3381) and will put it on my agenda | to revisit it next time I come back to error reporting. | | Thanks, | | -john | | On Jan 25, 2008, at 6:52 PM, Joerg Hohwiller wrote: | | Hi there, | | typically if maven fails with something like required artifact is | missing | you can have a look at the module where the error occurred and scan | the dependencies. | As additional support maven typically prompts an error report including | something like this: | | ~ Path to dependency: | ~1) net.sf.mmm:mmm-uit-impl-swt:jar:0.9.0-SNAPSHOT | ~2) org.eclipse.swt:swt:pom:3.3.0 | ~3) org.eclipse.swt:swt-linux-gtk:jar:3.3.0 | | Excellent. | | However there are still many situations where somewhere deep inside maven | an artifact is required that is missing but the user does NOT get a | tiny clue | what is going on. | In most cases you do not know which plugin requested the artifact and | caused the | problem or anything like that. | Even worse sometimes the required artifact is obviously located in the | local | repository but for some reason maven says it is missing. | I still remember several times where a buggy plugin was released and | my maven | got an update and further builds all ended with something like | maven-resources-plugin not found. | | I really love maven! It is great, it is cool, it rescues the world. | But sorry to say this: the logging and error handling in maven is | (partially) | shitty. | You know these kind of | This project has been banned from further executions due to previous | failures | but however there are no previous failures even if you start with -X. | In these moments a user comes to the point that maven is just a magic | wizzard | and if he is in a bad mood you can not do anything against it. | | Or what about eclipse:eclipse and the reactor summary that says | all is successfully but if you really read the entire log you will see | that many errors occurred? | IMHO there is a design problem in the way a MOJO can report an error. | If it throws a MojoExecutionException or -Failure the complete build | stops | (except for -fn and maybe -fae). | If it does NOT, the maven-core can not know the problem and the reactor | summary says SUCCESS. | | So please do not get me wrong. I want to say thanks for maven which is an | excellent product but please consider improving exception handling, error | tracking and logging in 2.1 and above as well as all mojo developers | (including | myself) should do. | | Best wishes | ~ Jörg | - - To unsubscribe, e-mail: [EMAIL PROTECTED
Re: Fix missing POM files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Carlos, | great, but | - who is going to enforce it? Sorry, I can not tell. Of course this is not easy to do. But you do have policies for your repository. It seems that they are not enforced or not strong enough. The best thing for a formal rule is to have a technical solution that prevents the rule to be violated. I just wanted to make sensible for the impact of changing the repository. | - who is going to say what the right pom is for a project that doesnt | build with Maven? Another good question. However, in our case we were talking about artifacts that have no pom. Then maven assumes a default pom with no dependencies. All that was suggested was to add this default pom explicitly. If this is wrong, it was wrong from the time the artifact was added. The policy is not to change artifacts after they have been deployed. So the project has to deploy a new version if the pom is wrong! A technical answer for your question is that you can use things like classpath helper to answer this. Anyhow you are right, that only to project owners should decide how there pom should be like. IMHO this is not the question here for the version that is already released. | | there's still people saying that poms should be modifiable! The chaos is already big enough. Please do not make it worse! Poms are modifyable but they should not be for releases in repositories like our central repo. | | and the fact that maven is ready for business doesnt mean taht you can | use anything however you want, you should enforce policies on what | plugin versions you want, what third party libraries,... because we | may take decisions here that will affect the decisions at some | companies, while not at others. Many times there's not black or white You are right. But again I just want to say be as sensible about changes as possible. Therefore my oppinion is: yes add these poms but without dependencies. If dependencies should be added, new versions have to be created. Take care ~ Jörg | | | On Jan 25, 2008 4:16 PM, Joerg Hohwiller [EMAIL PROTECTED] wrote: | Hi there, | | I am sometimes late on threads but anyways... | | | i don't agree, the point of not having a pom there is to be able to | | add one later with the right info. If you work against something | | without pom, hey, it's your decision, but you are aware that it's a | | problem, as all the warnings tell you | I do NOT agree. Adding a jar and later some pom with dependencies is | odd. You should enforce that no artifacts can go to central repro | if they do not come with a proper pom. | To fix the actual problem default poms should be added to | the repository. Further versions of these artifacts can add the | correct dependencies. | Please consider that maven is not just used by open-source users for fun but | also by brute business. If some company is running a deployment | that comes to a wrong result because of dependencies in a | pom that was just added to the repository (e.g. because then a different version | than before was chosen for a dependent artifact), they will flame maven. | Don't we say that maven is also ready for business? | Do you have an idea how much harm the maven community has done to enterprise | (and other) users by releasing buggy plugins? | I do not want to blame anybody! Giving your spare time for open-source is | worth some honor and humans make mistakes. But we should be aware of the | sensibility of our decisions. | | Best regards | ~ Jörg | | | | | On 10/15/07, William Ferguson [EMAIL PROTECTED] wrote: | | Isn't the goal here to stop incessant warnings during a build about | | trying to downalod a missing POM? | | | | The way to do that is to that is to upload a POM for that artifact to | | the repository. | | | | But Nico is right is that the uploaded POM should not break existing | | builds. Which means that the POM just needs to be bare bones and list no | | dependencies as the missing POM introduces no deps. | | | | So Nico, I'd suggest you create a simple POM with just groupId, | | artifactId and version and get it uploaded to the repository. | | | | Can I also suggest that it is a worthy task to auto generate and upload | | such POMs for all artifacts in central with a missing POM. | | | | William | | | | | | -Original Message- | | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos | | Sanchez | | Sent: Tuesday, 16 October 2007 2:01 AM | | To: Maven Developers List | | Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files - Email has | | different SMTP TO: and MIME TO: fields in the email addresses | | | | sorry, but that's not the case currently. If it has no metadata it can | | be added, that's why you get warnings when the metadata is missing. | | | | On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: | | I fully agree about collaborating and submitting more artifacts to the | | repo with good meta-datas. The only issue I can see is about
Re: Fix missing POM files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I am sometimes late on threads but anyways... | i don't agree, the point of not having a pom there is to be able to | add one later with the right info. If you work against something | without pom, hey, it's your decision, but you are aware that it's a | problem, as all the warnings tell you I do NOT agree. Adding a jar and later some pom with dependencies is odd. You should enforce that no artifacts can go to central repro if they do not come with a proper pom. To fix the actual problem default poms should be added to the repository. Further versions of these artifacts can add the correct dependencies. Please consider that maven is not just used by open-source users for fun but also by brute business. If some company is running a deployment that comes to a wrong result because of dependencies in a pom that was just added to the repository (e.g. because then a different version than before was chosen for a dependent artifact), they will flame maven. Don't we say that maven is also ready for business? Do you have an idea how much harm the maven community has done to enterprise (and other) users by releasing buggy plugins? I do not want to blame anybody! Giving your spare time for open-source is worth some honor and humans make mistakes. But we should be aware of the sensibility of our decisions. Best regards ~ Jörg | | On 10/15/07, William Ferguson [EMAIL PROTECTED] wrote: | Isn't the goal here to stop incessant warnings during a build about | trying to downalod a missing POM? | | The way to do that is to that is to upload a POM for that artifact to | the repository. | | But Nico is right is that the uploaded POM should not break existing | builds. Which means that the POM just needs to be bare bones and list no | dependencies as the missing POM introduces no deps. | | So Nico, I'd suggest you create a simple POM with just groupId, | artifactId and version and get it uploaded to the repository. | | Can I also suggest that it is a worthy task to auto generate and upload | such POMs for all artifacts in central with a missing POM. | | William | | | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos | Sanchez | Sent: Tuesday, 16 October 2007 2:01 AM | To: Maven Developers List | Subject: [***POSSIBLE SPAM***] - Re: Fix missing POM files - Email has | different SMTP TO: and MIME TO: fields in the email addresses | | sorry, but that's not the case currently. If it has no metadata it can | be added, that's why you get warnings when the metadata is missing. | | On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: | I fully agree about collaborating and submitting more artifacts to the | repo with good meta-datas. The only issue I can see is about | reproductible builds if those meta-datas change. | | The established rule NOT to change meta-datas after publication | applies IMHO also to artifacts without meta-datas. Anyone providing | metadatas for an artifact that is allready in repo, so that can be | used by many people, will potentialy break there builds, with no way | in maven2 to quickly fix this issue by stopping the transitive | dependencies. | Nico. | | 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: | On 10/15/07, nicolas de loof [EMAIL PROTECTED] wrote: | I'm not the guy who uploaded castor 1.0 on the maven repo, and I'm | also | not | the guy who used it in the project. I came later and have to | maintain | the | project now. | that's collaboration ;) if you want to use something that uses | castor and want to do it the right way, yes you should contribute a | pom | | Do you think I should contribute an empty POM just to ensure | no-one can latter contribute one with some (maybe) unexpected | dependencies ? | not an empty pom, but it shouldn't take more than 10 min to figure | out what the dependencies are | | A better solution IMHO should be to have an option for a | dependency in | my | POM to excludes all transitive dependencies. The current | exclusion elements require to list dependencies. With such a | feature, a project | that | has legacy reference on a dependency with no POM can simply set | no-transitivity to be reproductible in any case. | that's already filled in jira | | Many artifacts in the repo don't have POMs (from m1 - m2 | migration ?) | not lately but old ones, yes | | Nico. | | 2007/10/15, Carlos Sanchez [EMAIL PROTECTED]: | On 10/11/07, nicolas de loof [EMAIL PROTECTED] wrote: | Warning : This could break existing projects ! | | My project has a dependency on castor-1.0. This one has no | POM. | If you povide one, rebuilding my app will introduce new | transitive dependencies that were not expected, and my build | will become non-reproductible. | | Only new release of an artifact can come with a POM. | | mmm, that's not the case, you shouldn't made releases of things | without poms, you should have contributed one already | | | Nico. | | 2007/10/11, Jochen Wiedmann [EMAIL
source of missing dependency unclear
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, typically if maven fails with something like required artifact is missing you can have a look at the module where the error occurred and scan the dependencies. As additional support maven typically prompts an error report including something like this: ~ Path to dependency: ~1) net.sf.mmm:mmm-uit-impl-swt:jar:0.9.0-SNAPSHOT ~2) org.eclipse.swt:swt:pom:3.3.0 ~3) org.eclipse.swt:swt-linux-gtk:jar:3.3.0 Excellent. However there are still many situations where somewhere deep inside maven an artifact is required that is missing but the user does NOT get a tiny clue what is going on. In most cases you do not know which plugin requested the artifact and caused the problem or anything like that. Even worse sometimes the required artifact is obviously located in the local repository but for some reason maven says it is missing. I still remember several times where a buggy plugin was released and my maven got an update and further builds all ended with something like maven-resources-plugin not found. I really love maven! It is great, it is cool, it rescues the world. But sorry to say this: the logging and error handling in maven is (partially) shitty. You know these kind of This project has been banned from further executions due to previous failures but however there are no previous failures even if you start with -X. In these moments a user comes to the point that maven is just a magic wizzard and if he is in a bad mood you can not do anything against it. Or what about eclipse:eclipse and the reactor summary that says all is successfully but if you really read the entire log you will see that many errors occurred? IMHO there is a design problem in the way a MOJO can report an error. If it throws a MojoExecutionException or -Failure the complete build stops (except for -fn and maybe -fae). If it does NOT, the maven-core can not know the problem and the reactor summary says SUCCESS. So please do not get me wrong. I want to say thanks for maven which is an excellent product but please consider improving exception handling, error tracking and logging in 2.1 and above as well as all mojo developers (including myself) should do. Best wishes ~ Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHmnZTmPuec2Dcv/8RAg90AJ9GS+5og9hs1Iw371GfFNH/0dNjrQCgkuGw sQRXaoKucjsMvDjXYcHtpxM= =DCZ/ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven.test.skip and phases test and integration-test
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I noticed that maven.test.skip is just a convenience property specially interpreted by plugins like surefire. Besides I could NOT find a way to skip integration-tests when tests are configured to run in that phase instead. This causes the build to fail even with mvn -fae so other developers are blocked by invalid integration tests. I just wonder why it isnt possible to just tell maven to skip the entiere test and/or integration-test phase via some commandline option (just like - -Dmaven.test.skip=true). This would make it a lot easier and generic than having some conventions that several plugins need to support. Please note, that I have some modules where I have to do tests using the exec-maven-plugin. Since I do this in the test phase the suggested approach (skipping the test phase) would work while obviously the exec-plugin does NOT care about a property like maven.test.skip since it does NOT know if it is used for running tests or other things. Maybe you can give me a good reason for the current design or I am just missing some (undocumented) feature. If not, should I open a JIRA issue and are you willing to change/support this in future versions? Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGxeGJmPuec2Dcv/8RAmjCAJwNtb/2W6wOUtXwA5pWlaiL0dZi+wCgiocy pmvnJC/RdG9RkqFGz0O5RVM= =nUpa -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: avoid that central repo gets garbage dump
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, The biggest problem as I see it is not the groupId structures (although it DOES bother me...) but rather the dependencies metadata which is often incorrect, or atleast not quite right. Examples are numerous and range from optional dependencies marked as required, testing dependencies in compile scope, missing dependencies, etc. Not to mention informative metadata which is often missing. The problem is, many times we allow poms in the repo about projects we know nothing about, or at least not enough. For instance, I could post an upload request to Carlos for a private project of mine; Carlos has no idea (nor should he have, of course) about my project, the dependencies it needs, etc. So if I wrote a crappy pom, that's what goes in the repository. Now think what happens when it's not a private project, but I was simply the first person to post the upload request. The (bad) metadata is there for good, due to backwards compatibility which Carlos guards (and rightfully so). I see the solution in two layers: 1. Start over with a fresh repository (optional; we could go to an incremental solution instead) 2. Start creating a federated repository maintainers network for select projects/groups. For instance, say I know Hibernate very good and I request the maven team to make me the repo maintainer for the org.hibernate groupId. Now, if I know Hibernate better than Carlos (no offense - just an example, I don't really know Hibernate that much), and Hibernate is my main bread and water, I will probably do a better job at mainaining the metadata. Note that having the actual project committers maintain their own pom is always the best solution, of course; so if the Hibernate team wants to do so - that always was and should stay the preferred solution. WDYT? I have to think about 1. But 2. is a very good approach that I would agree immediatly. Yep, we should have maintainers for specific groupIds (I think somehow we already have this e.g. for javax, etc. - but it is not really handled properly). And yep, the first candidate for the maintainer of a groupId would be the somebody out of the team that develops the artifacts. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGP2YJmPuec2Dcv/8RAsM2AJ41r/n4hRZ4Xq6P48Pk59dZIkyHAACdFctT Do81iANpcc8Sch+OOo0hvgU= =5znd -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: avoid that central repo gets garbage dump
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Hello, I'd like to throw in my 2 cents. The maven repository was (as I recall) started back in the Maven 1.x days, when people didn't REALLY do ANY dependency management. Since then, the repository grew, Maven1.x grew and grew. A while later, Maven 2.x was released, and AFAIK the Maven 2.xrepository is a conversion of m1's repository. One of the biggest advantages and DRAWBACKS of the m2 repo is that *there is no removal or modification of existing artifact versions to preserve backward compatibility. This is a valid argument - but it is also our achiles' heel, due to the amount of bad metadata already there. Perhaps it is time we put all our knowledge we at the maven community have acquired over time regarding PROPER dependency management and declaration, in order to create a new project CLEAN repository, where all groups are really mapped to actually owned domain names (no more xerces groupId, for instance) and all metadata is validated and agreed upon. Start afresh. I've noticed the http://repo1.maven.org/maven2-repoclean-java.net/; repository, which seems like a nice starting place, though I'm not sure what it's for, really. What do you think? Well generally this sounds like a good plan to create a clean repository. Anyways I doubt how this finally solves the problem... Can we then just deprecate the current central repo? I have done big migrations in business tasks and from my point of view we have better chances if we take smaller steps and live with some legacy. Anyways a very easy idea for old groupIds could be to serve them as server-redirects. So lucene could automatically redirect to org/apache/lucene so it would be possible to gracefully migrate the deprecated groupIds in exsiting projects. The technical challange will just be the way to sync such information to all mirrors (might work via .htaccess files but they can be a security problem). A very little but still helpful thing to do, would be to put some index.html files in the deprecated groupId folders that point out to the problem and give a link to the new location. A lot of people just dig in the repository with their web-browser and sometimes people get lost in some folder like springframework and wonder why there is no up-to-date version. Additionally some metadata could be made available so that maven dumps a deprecation warning whenever such obsolete groupId is used in a POM. Best regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGPiyRmPuec2Dcv/8RAjb5AJ4uDZZckEQyvWV/AT8gAH/gm1rxNwCgmEnJ vDMqsJ5z+YpSXaIDIRTkQDU= =uz/V -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
avoid that central repo gets garbage dump
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I am seeing more and more the need that the community takes better control over what is dumped into the central repo. This seems to get more and more like a rubbish dump. There are duplications of the logically same artifacts. This causes extremly ugly situations in projects with a high level of integration, because you may end up with the same code multiple times in your classpath. To point this out just two examples: javax.persistence with 3 different groupId's: http://repo1.maven.org/maven2/javax/persistence/ http://download.java.net/maven/1/javax.ejb/jars/ spring: http://repo1.maven.org/maven2/org/springframework/ there is an all-in-one actifact (spring) as well as fine modularized artifacts (spring-core, etc.). You might say that this is the problem of the projects producing such artifacts. If you ask me this is also a question about wether maven2 is a real success or not. In such situations I hear many people scream that dependency management is the gate to hell. It is definetly not, but you get punished by the bad work of the others. And if you look at the zoo of senseless dependecies of apache artifacts such as xerces or some of the commons it is really a pitty! Please also consider that it is NOT an option to remove or modify an artifact from the central repository. There is the need to tripple-think about it before adding an artifact to the central repository ESPECIALLY if the one putting it into the repository is NOT the creator of the artifact. I am already active on the mailing-lists of several other open-source projects trying to convince the people about the need and the impact of maintaining their artifacts properly themselves for being uploaded to ibiblio. It is somewhat strange that even apache-projects like lucene or POI dont think much of maven and need to be convinced that it is worth the effort of providing valid and senseful POMs for their artifacts and staging them to ibiblio. For lucene I provided the POMs for some contrib half a year ago and nothing happened so far. Greetings from a maven fan that is a little frustrated Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGO5dymPuec2Dcv/8RAhS7AJsFQK0ro4tECUhvtdqXNJ2GYy2WgACdGBXY igNS02rPP8PH1lA1rVYiIJg= =9+xA -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
advanced dependency excludes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, while just submitting a bug to maven-dependency-plugin for NOT working when to include or exclude multiple groupIds (MDEP-87) I thought about it and ask myself: Why isn't this implemented in the maven core itself? Then all plugins could benefit from this feature. So what I am talking about is a way to match all artifacts just by a groupId in an exclude of a dependency: dependency groupIdorg.apache.foo/groupId artifactIdfoo-main/artifactId version1.0/version exclusions exclusion groupIdorg.codehaus.bar/groupId !-- artifactId*/artifactId -- /exclusion /exclusions /dependency So what do you think? Should I submit this as feature request in MNG or is it adressed already? Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJmELmPuec2Dcv/8RAlWiAJ9QWw57dHhgSU7t9CtL0VIfVIlsngCfZUHk ejlCkHzN2aDp517gQUKQAvQ= =W/t8 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency on system library (java.library.path)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Marc, We can change the license to something else, no problem. Of course this is your decision. But you could think about dual licensing your project. Here is something to consider: http://wiki.apache.org/jakarta/Using_LGPL'd_code Regards Mark Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJSIlmPuec2Dcv/8RAgspAJ9YrsHLqoCqVxAitYaoILrunpVCNQCfUZ7Q Ue1dhmXwUCpQ0BGSIQ4DJSw= =v4kR -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency on system library (java.library.path)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, On 4/12/07, Aaron Digulla [EMAIL PROTECTED] wrote: Joerg Hohwiller wrote: Hi there, I have already used SWT and GWT together with maven. Both need native system libraries at some specific point. This causes trouble when running code (e.g. test-cases) with maven. The latest 3.3 release of SWT includes the library files in the JAR! I have no idea how they do it and how the Java VM can find and load these but it works. Maybe you could ask the SWT guys how they did it and http://java.sun.com/j2se/1.4.2/docs/api/java/lang/System.html#loadLibrary(java.lang.String) Thanks to everybody for this valuable infos. Cheers Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJSJ6mPuec2Dcv/8RAjzMAKCIth+q+bS11TMst1OgIr2Vin3BOQCgiotn EgN3qFaNJg76yyjZbS5aIX8= =m6gW -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with separation of java and resources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm not sure if eclipse supports it, but with IDEA, the package view keep the resources and the java sources together. Great for the IDEA users, but this does NOT help me with eclipse. Can someone point out why it was designed this way? The src/*/java folders could also be used as resources directory with exclude filters on *.java (and potentially package.html, overview.html and doc-files/**). Do NOT get me wrong - I see that it is NOT a good idea to change this anymore in the Super-POM or the maven-jar-plugin, but I would like to understand. Maybe there is something I am missing that would help me to live better with the inconvenience or prevent me from adjusting this in my toplevel POM. Thanks Jörg Joerg Hohwiller wrote: Hi there everybody, from the separation of concerns view of the maven plugins I can see the point in separating java and resources in src/main and src/test. - From the users point of view this is quite ugly: -If you are looking at a java file and want to look at a related resource, you have to navigate all the way up out of java and back into resources down to the same package. Developers are used to find them right beside their java files. -The situation gets even worse if you look at package refactoring: You have to perform the same refactoring twice. If you make a little spelling mistake (or you simply forget to do it twice) you break your code. Maybe I am using the wrong IDE (eclipse), but ... What are the arguments for this separation? Isn't the resources plugin generic enough to include all files except *.java from java? Could this be done by configuration in the POM? (the super POM???) Regards Jörg - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGHVoimPuec2Dcv/8RAlVBAJ0eADal3s33NeD7nRZR6MTZ1I5E4ACeNbvQ xPeB4EQarWNngcIbvIOtQq8= =S7z0 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency on system library (java.library.path)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Hello Mark, the freehep-nar-plugin does exactly what you describe. http://java.freehep.org/freehep-nar-plugin Thanks for the hint. This sounds promising. Anyways I am not creating system libraries, I just want to use them in my project. From your documentation I could not really find how to get startet in putting the *.so and *.dll files in a NAR file and define this as dependency so my test-cases will have this available in java.library.path. Can you give me another hint how to archieve this? Regards Mark Donszelmann Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGGsQ9mPuec2Dcv/8RAqHRAJ9XVaB/LpVdkMxo7A+F9m9UtT8K3gCfY4tI WP8yvDPbVyxDUD4lCCVLRtg= =Nu4R -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MSITE-138: showstopper still without solution?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joerg Hohwiller schrieb: Hi there, Hi again, for those who dig in the archives and hit this thread: The problem has been solved. Fixes for JXR and cobertura are not yet released but this is just a matter of time. For JXR a fixed version is already available from the snapshot-repository. Regards Jörg since may 2006 the following issue is blocking the site gerneration of serious projects: http://jira.codehaus.org/browse/MSITE-138 This issue has been closed with the message that it has been fixed in version 2.0 of the site-plugin. I tried to get this version from any repository but could not get it. Next I tried to build it myself but figured out, that it can not be build with maven 2.04. To build the new version I had to use maven 2.1 and build the complete set of maven plugins. Somehow this also failed. I downloaded various integration builds of maven 2.1 but have never been able to build my project with one of those at all. I have posted about these problems on the list, but did not get anything that solved my problem. E.g. On 29. Aug. 2006 Brett Porter reported about this: Ugh. I was -1 on the commit that caused this and it hasn't yet been fixed. I'll be rolling it back later today. IT should build with Maven 2.0.4 and no changes to the plugin plugin. I can't see that it needs the latter, but it certainly requires Maven 2.1 which is not good. Somehow it seems to me that there is still no solution to this problem. For about half a year I am now stuck with my project site and have to update it with a lot of stupid manual work. Is there a roadmap for maven 2.1 and all the new plugin releases that can not be released before? Or is there a way to fix this with maven 2.04 that I am missing? Thank you so much Jörg - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGFppkmPuec2Dcv/8RAsL0AJ0VECI+xABESghAceiPZKLQSZjbDQCfWvMX zdAIrjlNSr8Z786E27U3fto= =o9F4 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
dependency on system library (java.library.path)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I have already used SWT and GWT together with maven. Both need native system libraries at some specific point. This causes trouble when running code (e.g. test-cases) with maven. Are there any plans to add dependencies with typedll/type (or typeso/type) to java.library.path? For system libraries however the name cares when it is loaded from something that I can not control (foo-1.0.jar loads foo.dll and it can not be named foo-1.0.dll). Is there a way to put various artifacts with different versions but the same file-name into a maven repository? In other words: The filename of an artifact is automatically derived from artifactId, version, classifier and type. Is there a way to override this default behaviour and specify an explicit name? Example: org/eclipse/swt/swt-win32/3.2.1/swt-win32.dll org/eclipse/swt/swt-win32/3.2.2/swt-win32.dll dependency groupIdorg.eclipse.swt/groupdId artifactIdswt-win32/artifactId version3.2.2/version typedll/type scoperuntime/scope !-- something like this -- filenameswt-win32.dll/filename /dependency Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGFp6EmPuec2Dcv/8RAoDjAKCJrr0xdI3iXUvYzLYiE2RLi45XLgCfThMo 1ecdAOdt55WlfcTYfE7AS+k= =W5G2 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency on system library (java.library.path)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Eric, It should be a type, I agree. But if you are trying to keep moving, I just drop the dll in the repo directory with the GWT jar. Thanks for the hint. This works for the GWT but NOT for a raw SWT project. Eric Regards Jörg On 4/6/07, Joerg Hohwiller [EMAIL PROTECTED] wrote: Hi there, I have already used SWT and GWT together with maven. Both need native system libraries at some specific point. This causes trouble when running code ( e.g. test-cases) with maven. Are there any plans to add dependencies with typedll/type (or typeso/type) to java.library.path? For system libraries however the name cares when it is loaded from something that I can not control (foo-1.0.jar loads foo.dll and it can not be named foo-1.0.dll). Is there a way to put various artifacts with different versions but the same file-name into a maven repository? In other words: The filename of an artifact is automatically derived from artifactId, version, classifier and type. Is there a way to override this default behaviour and specify an explicit name? Example: org/eclipse/swt/swt-win32/3.2.1/swt-win32.dll org/eclipse/swt/swt-win32/3.2.2/swt-win32.dll dependency groupIdorg.eclipse.swt/groupdId artifactIdswt-win32/artifactId version3.2.2/version typedll/type scoperuntime/scope !-- something like this -- filenameswt-win32.dll/filename /dependency Thanks Jörg - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGFqSVmPuec2Dcv/8RAgVJAKCHDiFlqqypM5I7/F5HFNzPYSHLpQCfXSqs cc85ajbba0+YNQDCCkT/trc= =IxmV -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
site:stage trouble - HELP, please
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everybody, I am figthing with site:stage and am quite desperate now :( Could you please help me with MCOBERTURA-63? http://jira.codehaus.org/browse/MCOBERTURA-63 I am totaly clueless and actually I want to USE maven instead of DEVELOPING maven. But since I am wating for about one year to be able to update my projects website automatically with maven, I digged into various MOJOs and really got dirty ;) Anyhow MCOBERTURA-63 seems to indicate a deeper problem I am NOT able to solve. Could some maven guru please take a look the problem. You can find parts of my history here: http://jira.codehaus.org/browse/MSITE-138 After all I still think that maven is a really cool tool. Please do not loose me faith - I feel so totaly lost... Thank you guyz Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF1PAHmPuec2Dcv/8RAqPXAJ9zHNrocKYBSLdpxZBf1QYc736bgwCfUTin W1K+YXrxpiMnOWsuOeYtilE= =+U5w -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and JDK 1.6
Hi there, Here's the issue I discovered with 2.0.4 and JDK 6. AppFuse 2.x users have reported other issues (i.e. plugins not firing) when using JDK 6. http://jira.codehaus.org/browse/MNG-2709 Matt FYI: I am using maven2 with JDK6 and had no problems so far. I am using junit4 and I only get the error described in the issue above, when I miss to add junit at all to a toplevel pom. Anyways I experienced slightly differences of JDK6 when dealing with XML (e.g. XmlUnits fail with JDK6 that work with any JDK = 5, might be a bug in JAVA6) and also when using collections (iterator orderung of unordered collections changed, but this one is NOT a bug). Regards Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-solaris-plugin
Hi there, for those who are interested: http://jira.codehaus.org/browse/MNG-2761 Please get into discussion about creating deployment packages (also DEB, RPM, etc.) with maven. Regards Jörg Hi I think the best way is to create an issue for the sandbox component http://jira.codehaus.org/browse/MNG Cheers, Vincent 2006/8/29, Joerg Hohwiller [EMAIL PROTECTED]: Hi there, as I promised some time ago, I wanted to provide my work in creating a maven2 plugin for solaris packaging. I uses an ant mojo and only works on a solaris machine with pkgtools installed. For the moment I set in the POM groupId to org.apache.maven.plugins and artifactId maven-solaris-plugin. Should I set groupId to org.codehaus.mojo instead? Where should I put the current state? I have the plugin itself and a dummy example project that is using the plugin. Should I create the example as archtype? Best regards Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Releasing the site plugin
Hi there, I had no specific objections once the 2.1-SNAPSHOT dependency was removed. There are 2 open issues for the current version, though, and I'm a bit concerned at releasing it as final when there are 64 other issues open. Should it still be beta? +1 I just want to get the fixes out out that are there and try to do more frequent releases once the releasing stuff properly is a little easier. Not sure about the beta thing. I might take a look at it for the next rev but I really don't know what the feature set is and how polished it is. Someone else's call on the beta. Could someone deep inside the maven plugins have a look at MSITE-138. I uploaded a testcase to reproduce the issue. As it seems from MSITE-15 this bug was reported first on 03.11.2005, more than one year ago... jason. Thanks Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
problem with separation of java and resources
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there everybody, from the separation of concerns view of the maven plugins I can see the point in separating java and resources in src/main and src/test. - From the users point of view this is quite ugly: - -If you are looking at a java file and want to look at a related resource, you have to navigate all the way up out of java and back into resources down to the same package. Developers are used to find them right beside their java files. - -The situation gets even worse if you look at package refactoring: You have to perform the same refactoring twice. If you make a little spelling mistake (or you simply forget to do it twice) you break your code. Maybe I am using the wrong IDE (eclipse), but ... What are the arguments for this separation? Isn't the resources plugin generic enough to include all files except *.java from java? Could this be done by configuration in the POM? (the super POM???) Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFFiGoBmPuec2Dcv/8RAsukAJ4k+CWrrCYzlOFR2k8mMFQIOyLUMACfRZs2 uf+RM6+QFoPUmPJtbgyYDX8= =QFMc -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Site Plugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jason, [cut] thanks for your work. I tried to build my site with maven 2.0.4. and maven-site-plugin 2.0-SNAPSHOT and now javadoc seems to work even if the site is staged (site:stage). I do not know if that was intended by your fix. But maybe this only happened, because maven-javadoc-plugin was updated, too. Anyhow jxr and cobertura are still broken, so MSITE-138 is still not fixed for maven 2.0.4: http://jira.codehaus.org/browse/MSITE-138 Do you think you could give me a sample project with the projects configuration that you have. I have run Cobertura and JXR on some of Joakim's sites so we'll track it down. Give me an example of what you have that doesn't work and I'll track it down. First of all, thanks for taking care. My project has public subversion access here: http://m-m-m.googlecode.com/svn/trunk/ I used the official maven 2.0.4. To ensure there are no strage side-effects from other experiments, I cleared my local .m2/repository. I setup my settings.xml as described in http://maven.apache.org/guides/development/guide-plugin-snapshot-repositories.html To ensure that maven-site-plugin is used in the 2.0-SNAPSHOT version, I added this explicitly to my master pom: ... build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId version2.0-SNAPSHOT/version /plugin ... When I run mvn -Papache site:stage -DstagingDirectory=/foo/bar I still have the problem with jxr and cobertura. I use java 6 to compile my project. I also tried it with java 5, but it does not work eigther. I cannot build my project with java 1.4 or lower since I am using lots of syntactic sugar ;) If you want to reproduce the problem you will get the problem, that the complete build will not work because there are dependencies missing, not (yet) available in central repo. But if you just ignore those and run an mvn -Papache install followed by the site:stage command above both as far as it works, you will already see the problem in the modules that have successfully been completed (e.g. mmm-nls-core). If you find it too inconvenient to dig in my project, let me know and if I can find the time, I setup a little demo to reproduce the problem. My experience is that this happens in any multi-project situation together with site:stage or site:deploy. With a plain site everything works fine but the site for the complete project itself is not useable because the links between the projects are broken. For maintaining my project site I realy need site:stage to work properly. I am waiting for this to work for over half a year now and am very happy to see that a fix for this show-stopper is finally making big progress. I also digged in the sources and tried to think about a fix but I got lost since the complete head of the maven plugins was not compileable and the dependencies went so deep down, that I got lost. I also tried it with maven 2.1 and gave up after a cuple of frustrating hours. I worte my own MOJO and have a little understanding of plexus and the maven architecture - but really understanding the whole animal is not a task of a cuple of hours... Anyhow from what I have seen you have done great with maven2 - - maven1 was realy a hack (sorry for that, but it just worked and thats it) and maven2 is a designed piece of software. Thank you very much for your effort!!! Did I get something wrong. Was your fix about something else? I was only trying to get it to run in 2.0.4 and make sure that worked. I am still not sure if I got you right about what you fixed and what worked for you. But maybe you can now reproduce the problem I (and many others) have with maven2 (2.0.4). Anyhow since javadoc works I get the impression, that your maven- site-plugin fixed prepared something so the reports can now work with site:stage but only maven-javadoc-plugin has already been fixed to work together with this new fix while jxr and cobertura still do something wrong. Can anybody enlighten my nescience? I have not actually tried to close any issues in the site plugin myself :-) Just wanted to make sure it's all working for 2.0.4 users. I did not want to arrest you for my problems. But MSITE-138 is a real show-stopper and I pick up on every trace I can get about this one. E.g. my mail MSITE-138: showstopper still without solution? (03.12.2006 16:03) on dev@maven.apache.org seemed to be an helpless scream that got lost in space ;) Jason. Thanks again Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFFhaObmPuec2Dcv/8RAukZAJ9Ju4GBV17A/i01jo3OLwXGWQTpXQCeL+nM eND9+hZKzdVRk62knnJCUJ0= =AOHt -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: Maven Site Plugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason van Zyl wrote: Hi, Hi Jason, thanks for your work. I tried to build my site with maven 2.0.4. and maven-site-plugin 2.0-SNAPSHOT and now javadoc seems to work even if the site is staged (site:stage). I do not know if that was intended by your fix. But maybe this only happened, because maven-javadoc-plugin was updated, too. Anyhow jxr and cobertura are still broken, so MSITE-138 is still not fixed for maven 2.0.4: http://jira.codehaus.org/browse/MSITE-138 Did I get something wrong. Was your fix about something else? Anyhow since javadoc works I get the impression, that your maven-site-plugin fixed prepared something so the reports can now work with site:stage but only maven-javadoc-plugin has already been fixed to work together with this new fix while jxr and cobertura still do something wrong. Can anybody enlighten my nescience? Regards Jörg I have managed to get the site plugin working with 2.0.4 and it really wasn't a simple matter of rolling back some stuff. In order for the site plugin to work with 2.0.4 the version of doxia that is in MAVEN_HOME/lib must be used which is doxia-1.0-alpha-7. The version of doxia in trunk is not very much like 1.0-alpha-7 at all and creating a bridge required a compat package with bits from maven- reporting, doxia-core, doxia-site-renderer, doxia-document-render. Maybe I'm missing something but I don't see how what's in trunk could work at all as there are so many class that are different with methods removed, or classes not present in doxia-1.0-alpha-7. Another problem was relying on some changes in plexus-utils that are not available in the version used in 2.0.4 I have created a tag in svn that marks the point right before I created the bridge for reverting if something is wrong here: http://svn.apache.org/repos/asf/maven/plugins/tags/maven-site-plugin- pre-compat-with-doxia-1.0-alpha-7/ I have created some notes about the compatibility here: http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-site-plugin/ compatibility-notes.txt I have checked in what I have that makes it work for the /maven/ components site generation and I have deployed a snapshot that people can try: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/ plugins/maven-site-plugin/2.0-SNAPSHOT/ So for that poor fellow who was trying to jump through rings of fire to generate his sites, this one's for you :-) Thanks, Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFFhIH7mPuec2Dcv/8RAmQnAKCDCOkbxC6PPv/Cs04Eg4CrjeZT4gCfbysA MmJrTGqaUUkhjknS9v/kYTU= =fZNs -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
MSITE-138: showstopper still without solution?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, since may 2006 the following issue is blocking the site gerneration of serious projects: http://jira.codehaus.org/browse/MSITE-138 This issue has been closed with the message that it has been fixed in version 2.0 of the site-plugin. I tried to get this version from any repository but could not get it. Next I tried to build it myself but figured out, that it can not be build with maven 2.04. To build the new version I had to use maven 2.1 and build the complete set of maven plugins. Somehow this also failed. I downloaded various integration builds of maven 2.1 but have never been able to build my project with one of those at all. I have posted about these problems on the list, but did not get anything that solved my problem. E.g. On 29. Aug. 2006 Brett Porter reported about this: Ugh. I was -1 on the commit that caused this and it hasn't yet been fixed. I'll be rolling it back later today. IT should build with Maven 2.0.4 and no changes to the plugin plugin. I can't see that it needs the latter, but it certainly requires Maven 2.1 which is not good. Somehow it seems to me that there is still no solution to this problem. For about half a year I am now stuck with my project site and have to update it with a lot of stupid manual work. Is there a roadmap for maven 2.1 and all the new plugin releases that can not be released before? Or is there a way to fix this with maven 2.04 that I am missing? Thank you so much Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFFcudAmPuec2Dcv/8RAp0GAKCJfM3Q2cN+ssLzgWqJmebQAjbI6gCeP72P gewT+zmhnGyA/XlXZo4A7dU= =wzsv -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
toc feature in xdoc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear developers, since I got no answer on the users list, I want to give it a try on the developers list: I am looking for a way how to create a table of contents automatically from the sections and subsections of an xdoc file. Is there a specific tag to do this or should I open a feature request in JIRA? Regards Jörg - Original Message Subject: toc feature in xdoc? Date: Sun, 29 Oct 2006 21:42:31 +0100 From: Joerg Hohwiller [EMAIL PROTECTED] Reply-To: Maven Users List users@maven.apache.org To: Maven Users List users@maven.apache.org Hi there, in the xdoc format one can create sections and subsections. Is there a simple tag that can cause the automatic generation of a table of contents? I have seen some projets out there that created this manually by adding named anchors and a manually written toc. This seems to be stupid work and hard to maintain. It would be quite simple for doxia to generate this automatically if some specific tag is present, right? Regards Jörg - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFFXhXfmPuec2Dcv/8RAtMGAJ9SWRuOJFaC3BWn7TvSg2yumv+jigCfbS3y D5gB7B/cu1dakOxARUKsFWU= =ltf4 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build maven plugins from trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Brett, Brett Porter wrote: Ugh. I was -1 on the commit that caused this and it hasn't yet been fixed. I'll be rolling it back later today. IT should build with Maven 2.0.4 and no changes to the plugin plugin. I can't see that it needs the latter, but it certainly requires Maven 2.1 which is not good. Has anything happened on that? This is still a blocker for many users. I tried to get the latetest integration build of m2 2.1-Snapshot but still could not build the head of the maven-site-plugin. Any suggestions or road-map infos about this one? Thanks Jörg - Brett On 30/08/2006, at 8:12 AM, Vincent Siveton wrote: Hi Jörg, Based on your comments, here are my succesfull steps to build maven-site-plugin from scratch: - dwl and install m2-20060828.203000.tar.gz - removed my repository - added snapshot repository (see [1]) - build Maven (see [2]) * svn co http://svn.apache.org/repos/asf/maven/components/trunk/ * mvn -Papache install * mvn -Pcodehaus install (if failed for some plexus or modello artefacts) - build maven site * svn co http://svn.apache.org/repos/asf/maven/plugins/trunk/maven- site-plugin * mvn -Papache install To use maven-site, you need also PIR plugin so: - svn co https://svn.apache.org/repos/asf/maven/plugins/trunk/maven- project-info-reports-plugin - mvn -Papache install HTH Could you provide us the full stack trace? I dont see any reference to maven-plugin-plugin:2.0-alpha-3. Cheers, Vincent [1] http://maven.apache.org/guides/development/guide-plugin- snapshot-repositories.html [2] http://maven.apache.org/guides/development/guide-building-m2.html 2006/8/29, Joerg Hohwiller [EMAIL PROTECTED]: Hi there, As fix for MSITE-138, I want to build the maven-site-plugin from trunk. As I figured out, I also need to update maven-plugin-plugin that also requires me to update maven itself. As suggested by Vincent, I got the latest integration build which was m2-20060828.203000.tar.gz (2.1-SNAPSHOT). I checked out http://svn.apache.org/repos/asf/maven/plugins/trunk and tried to build this with the new maven. Unfortunately I got stuck again. I always get: [INFO] Failed to resolve artifact. GroupId: org.apache.maven.plugins ArtifactId: maven-plugin-plugin Version: 2.0-alpha-3 Since maven did not tell me the path to this dependency, I decided to move my complete local repository (~/.m2/repository) away and start from scratch. Then maven only downloaded apache-3.pom and maven- parent-4.pom and then failed with the same error. As I greped in the downloaded POMs for maven-plugin-plugin, I got no results. To me it seems that maven itself is wired with the dependency on maven-plugin-plugin:2.0-alpha-3 (+). Since maven-plugin-plugin:2.0-alpha-3 is not available and I can not build maven-plugin-plugin I am stuck. Any suggestions what to do? Thanks a lot... Jörg - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFFJWeLmPuec2Dcv/8RAvNdAKCCyyw9jTmY+MQHp6fGjJr71LmshgCdGzmf ZWiHW42xlGYVSk5ezMFNQc0= =TUoE -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build maven plugins from trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Vincent, Could you provide us the full stack trace? I dont see any reference to maven-plugin-plugin:2.0-alpha-3. here it is... Jörg [EMAIL PROTECTED]:~/projects/maven-plugins/maven-plugin-plugin$ mvn -X install + Error stacktraces are turned on. Maven version: 2.1-SNAPSHOT [INFO] Scanning for projects... [INFO] [INFO] Building Maven PLUGIN Plugin [INFO]task-segment: [install] [INFO] Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin-plugin/2.0-alpha-3/maven-plugin-plugin-2.0-alpha-3.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugin-plugin/2.0-alpha-3/maven-plugin-plugin-2.0-alpha-3.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.maven.plugins ArtifactId: maven-plugin-plugin Version: 2.0-alpha-3 Reason: Unable to download the artifact from any repository org.apache.maven.plugins:maven-plugin-plugin:pom:2.0-alpha-3 from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Unable to build project for plugin 'org.apache.maven.plugins:maven-plugin-plugin': POM 'org.apache.maven.plugins:maven-plugin-plugin' not found in repository: Unable to download the artifact from any repository org.apache.maven.plugins:maven-plugin-plugin:pom:2.0-alpha-3 from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1269) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1517) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1011) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:975) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:393) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:182) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:747) at org.apache.maven.cli.MavenCli.main(MavenCli.java:380) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.InvalidPluginException: Unable to build project for plugin 'org.apache.maven.plugins:maven-plugin-plugin': POM 'org.apache.maven.plugins:maven-plugin-plugin' not found in repository: Unable to download the artifact from any repository org.apache.maven.plugins:maven-plugin-plugin:pom:2.0-alpha-3 from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository) at org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:265) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:183) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:163) at
build maven plugins from trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, As fix for MSITE-138, I want to build the maven-site-plugin from trunk. As I figured out, I also need to update maven-plugin-plugin that also requires me to update maven itself. As suggested by Vincent, I got the latest integration build which was m2-20060828.203000.tar.gz (2.1-SNAPSHOT). I checked out http://svn.apache.org/repos/asf/maven/plugins/trunk and tried to build this with the new maven. Unfortunately I got stuck again. I always get: [INFO] Failed to resolve artifact. GroupId: org.apache.maven.plugins ArtifactId: maven-plugin-plugin Version: 2.0-alpha-3 Since maven did not tell me the path to this dependency, I decided to move my complete local repository (~/.m2/repository) away and start from scratch. Then maven only downloaded apache-3.pom and maven-parent-4.pom and then failed with the same error. As I greped in the downloaded POMs for maven-plugin-plugin, I got no results. To me it seems that maven itself is wired with the dependency on maven-plugin-plugin:2.0-alpha-3 (+). Since maven-plugin-plugin:2.0-alpha-3 is not available and I can not build maven-plugin-plugin I am stuck. Any suggestions what to do? Thanks a lot... Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE9KrGmPuec2Dcv/8RAqJhAJ9PB2HYHeFEePG4weMaLvq4K0C9dQCeJFIV 7Z8hgrMavddpHyNMsNeOLeg= =ZK2r -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven-solaris-plugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, as I promised some time ago, I wanted to provide my work in creating a maven2 plugin for solaris packaging. I uses an ant mojo and only works on a solaris machine with pkgtools installed. For the moment I set in the POM groupId to org.apache.maven.plugins and artifactId maven-solaris-plugin. Should I set groupId to org.codehaus.mojo instead? Where should I put the current state? I have the plugin itself and a dummy example project that is using the plugin. Should I create the example as archtype? Best regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE9K7gmPuec2Dcv/8RAry4AJ45LMrZkDCjEuHHeBfMGv7VxNiNnwCbBfPZ F4ckVHeeS+aIYvQ7opVN9JI= =+1JG -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build maven plugins from trunk
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vincent Siveton wrote:
Hi Jörg,
Hi Vincent,
thanks for your quick reply...
Based on your comments, here are my succesfull steps to build
maven-site-plugin from scratch:
- dwl and install m2-20060828.203000.tar.gz
ok
- removed my repository
again and again ;)
- added snapshot repository (see [1])
had this setup...
- build Maven (see [2])
* svn co http://svn.apache.org/repos/asf/maven/components/trunk/
no worries
* mvn -Papache install
* mvn -Pcodehaus install (if failed for some plexus or modello artefacts)
both do not work - even
mvn -Papache,codehaus install
does NOT work:
[INFO] Building Maven Core
[INFO]task-segment: [install]
[INFO]
Downloading:
http://snapshots.maven.codehaus.org/maven2/org/apache/maven/plugins/maven-assembly-plugin/2.0-beta-1-SNAPSHOT/maven-assembly-plugin-2.0-beta-1-SNAPSHOT.pom
[WARNING] Unable to get resource from repository codehaus.plugin.snapshots
(http://snapshots.maven.codehaus.org/maven2)
Downloading:
http://people.apache.org/maven-snapshot-repository/org/apache/maven/plugins/maven-assembly-plugin/2.0-beta-1-SNAPSHOT/maven-assembly-plugin-2.0-beta-1-SNAPSHOT.pom
[WARNING] Unable to get resource from repository apache.snapshots
(http://people.apache.org/maven-snapshot-repository)
Downloading:
http://people.apache.org/maven-snapshot-repository/org/apache/maven/plugins/maven-assembly-plugin/2.0-beta-1-SNAPSHOT/maven-assembly-plugin-2.0-beta-1-SNAPSHOT.pom
[WARNING] Unable to get resource from repository apache.snapshots
(http://people.apache.org/maven-snapshot-repository)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
GroupId: org.apache.maven.plugins
ArtifactId: maven-assembly-plugin
Version: 2.0-beta-1-SNAPSHOT
Reason: Unable to download the artifact from any repository
org.apache.maven.plugins:maven-assembly-plugin:pom:2.0-beta-1-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
codehaus.plugin.snapshots (http://snapshots.maven.codehaus.org/maven2),
apache.snapshots (http://people.apache.org/maven-snapshot-repository)
- build maven site
* svn co
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-site-plugin
* mvn -Papache install
To use maven-site, you need also PIR plugin so:
- svn co
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-project-info-reports-plugin
- mvn -Papache install
HTH
Could you provide us the full stack trace? I dont see any reference to
maven-plugin-plugin:2.0-alpha-3.
Can not reproduce right now - therefore I get this for latest maven-plugins:
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-plugins/2/maven-plugins-2.pom
6K downloaded
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] The projects in the reactor contain a cyclic reference: Edge between
'Vertex{label='org.apache.maven.plugins:maven-javadoc-plugin'}' and
'Vertex{label='org.apache.maven.plugins:maven-checkstyle-plugin'}' introduces to
cycle in the graph org.apache.maven.plugins:maven-checkstyle-plugin --
org.apache.maven.plugins:maven-javadoc-plugin --
org.apache.maven.plugins:maven-checkstyle-plugin
Cheers,
Vincent
Thanks so far
Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFE9MLmmPuec2Dcv/8RAhj+AJsFH+plQQ/ll7BgasvUI6ZC9jjCNQCfZpjc
ZxNABwGRjXfswsDyBv3essU=
=O0iM
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
javax JARs at ibiblio
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, what is the actual state about javax JARs at ibiblio? I have seen that javax.mail is available as JAR in the central repo. Does this mean that potentially other javax JARs could be made available there? I would love to java javax.annotation available at ibiblio because in jdk1.5 it is not included and jdk1.6 is still a little bit too hot. Currently there is only an ill-stated version with a strange POM available. Are there any concerns about Suns Licensing or can I just create a bundle and submit an upload request? I mean as described in: http://maven.apache.org/guides/mini/guide-ibiblio-upload.html I currently think that this is still a licensing issue but maybe things have changed since Sun is going a little bit more towards open-source. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE7NZQmPuec2Dcv/8RAlUlAJ9tb+EtjNP+UwLlDXW7qx1J8ZHTOQCdHGax qe1jZWseTTO+eP2EhpffHto= =x6gh -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What do you think: add new endorsed dependency scope?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mike, SingleShot wrote: I have several cases where I need to override the default JDK implementations via the Java endorsed JAR override mechanism (for example, by setting java.endorsed.dirs). When I create a software distribution, I use the assembly plugin to place all runtime dependencies in a lib directory, and to place all JARs to be used in the endorsed JAR override mechanism in a lib/endorsed directory. I also proivde some platform-dependent script files used for launching my application(s), each of which sets the java.endorsed.dirs property on behalf of the user. One thing I don't like is that my assembly descriptors are all identical (since I follow this pattern on all my appllications) except for where I need to specify which dependencies are to be placed in the endorsed directory. It would add value for me if there were a way to list which Jars are endorsed, perhaps by adding a new dependency scope of endorsed. I could then make a generic assembly descriptor that places all runtime dependencies in lib and all endorsed dependencies in lib/endorsed. Does anyone agree that this would be a good addition to Maven, and if so, under what subproject would I post a JIRA issue? I have the same use case, too. So I agree on this. Thanks, Mike Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE5NDxmPuec2Dcv/8RAk96AKCWf2VGjEjSdmH781MLPQHflkiHZQCeLEwz eYV2YDvf4717OeDPmZ1qquQ= =mzLv -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: m2eclipse and transitive dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Graham Leggett wrote: Hi all, Hi, Do transitive dependencies work within m2eclipse v0.0.9? They do work for me. I have quite a lot of projects with many dependencies. In the case where eclipse project A depends on eclipse project B, and eclipse project B has a dependency on foo.jar, foo.jar is not made available to eclipse project A, and the build fails. Not in general. Please give more details... There also seems to be no way of refreshing the eclipse visible build path, and the dependencies in pom.xml. As far as I experienced, the dependencies get updated automatically whenever the pom.xml has changed. Since eclipse has a (pretty nasty) virtual filesystem you need to refresh the pom.xml or activate refresh automatically in your eclipse config. If the dependencies are edited in pom.xml, the Maven2 dependencies list blanks out, and the build fails. This happens when a dependency could not be resolved at all. Please inspect the log carefully and post more details. Is there active development on m2eclipse? I am not a developer but there is a new release from time to time. I also wait for a really usable release, though. For the moment you neet to live with mvn eclipse:eclipse if you want to work effectively with a large project. Regards, Graham -- Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE5NKymPuec2Dcv/8RAsXSAJ9BhqDj9ccOKko/Z9+MIDHzhdmMIgCfXzQd UldQzRfmJu/pBxgtSIEy/No= =0/Hl -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Multiple JDKs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jan, Jan Nielsen wrote: I'm a newbie to Maven and Continuum, so aplogies if this is obvious. I'm not sure if this is a Maven question or Continuum question, or perhaps both, so I thought I'd try here first. When dealing with multiple projects which need different JDK for compilation, it's possible to use the source and target elements for the maven-compiler-plugin for each project to define the desired byte-code: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0/version configuration source1.5/source target1.5/target /configuration /plugin but, to avoid JDK library swapping, I would much rather be able to defined which one of my multiple JDKs should be used for compilation and test execution, akin to what is done in Eclipse with configured JDKs. Is this possible in Maven and/or Continuum. Specifically, I have code which must be JDK 1.3 only, I have library code which needs to be JDK 1.3 compatible but typically runs in a JDK 5 environment, and I have application code which is JDK 5 only. My mixed-mode library code has backport of some of the JDK 1.4 and JDK 5 functionality which if I're running in JDK 5 environment I take advantage of via reflection; otherwise, these services are implemented with JDK 1.3 constructs. My test code needs to test both modes of operation, i.e., JDK 1.3 environments and JDK 5 environments so my unit tests for this library must be executed twice, once in each environment, and my code must be compiled in JDK 1.3. Does that make sense? Any thoughts? Can't you simply ensure that the desired JDK is the first item of the system path of your invoking shell. Something like export PATH=$MY_JAVA_HOME/bin:$PATH or set PATH=%MY_JAVA_HOME%\bin;%PATH% and then invoke mvn. Run a java -version before to verify your setup. If this works create a *.sh or *.bat file to make your life easier. Be arware that on windows systems the jdk binaries are dumped in system32 what is quite ahead in the path. So it does NOT work to set your users local PATH variable. Many thanks, -Jan Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE5NTPmPuec2Dcv/8RAnWHAJ47rwV3yUE+44DLRSsCYY5L8+LtJgCfWL1Z 4/lrapzh+VfSGUrU3NB3Lq4= =lxOj -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: maven2 and maven1 incompatibility]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I posted this on the user list but got no response. Maybe it was a little misplaced there and should better reach some of the maintainers... Take care Jörg - Original Message Subject: maven2 and maven1 incompatibility Date: Wed, 05 Apr 2006 23:24:09 +0200 From: Joerg Hohwiller [EMAIL PROTECTED] Reply-To: Maven Users List users@maven.apache.org To: users@maven.apache.org Hi there, I have been using maven and now m2 for quite a while. Anyways I just wanted to let you know that I often get mails from people who get in trouble because they want to use the software XYZ (e.g. scarab) and in the installation guide of that software you can read that you need to get maven to build the software and then run the following command maven foo bar. Now people who do not have a clue about maven go to the maven site and download the latest release and try the command above. Then they got lost because they simply do not know that they downloaded maven2 (mvn) what is incompatible to maven1 what they should have downloaded instead. Maybe some nice guy could place a little hint for those newbies on the download page. Take care Jörg - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEwXe3mPuec2Dcv/8RAjXgAJoDsdEfuztyPT9LjMGUXP4rKOAssQCfVD7i q0in8Znmvzg0glKSINFOS/Q= =q1D0 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven dependecies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jörg Have a look at the Better builds with Maven book. There's an example for a mojo and for an Ant based plugin. Thanks for the hint... I am going to work this out... Its unbelivable to have such documentation if you have been strzggeling with maven1... Great work... - Jörg Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEwXt5mPuec2Dcv/8RAjGHAKCPdGQoPKzGVm3dq9Aow+QxCSXNvgCfd1go nmhpfusTxkvA8LWbpzYDfTU= =rDzY -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Layout of multiproject projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Stephen, Stephen Duncan wrote: Two pieces of info: there is already an optional tag in the parent that allows you to specify where the parent is - relativePath: http://maven.apache.org/ref/2.0.3-SNAPSHOT/maven-model/maven.html#class_parent Also, rather than running with -N, you should look at the inherited option: http://maven.apache.org/ref/current/maven-model/maven.html#class_plugin - Stephen You helped me a lot with that. Maybe I should have posted this on the users lists ;) Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEwXwimPuec2Dcv/8RAiLVAKCWV2vrZtSYWfz/Ku4TWnIOWmCbggCaArhU yn5uJlBPEYXQUHkp8HJKDcE= =3YyF -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven dependecies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jörg Schaible wrote: Hi Jörg, Hi Jörg, nice to meet again ;) [snip] So did you have multiple modules for each Solaris package or a single module with a Mojo that creates two artifacts (like the EJB and its client)? I created one module per package. This is in principle the idea of maven to have one artifact per module. The only part that breaks out is the configuration package that is different for each machine where it will be deployed to (test, staging, live1, live2). For EXT and CUST I can put the dependencies in the parent POM. In your case I might have taken the second approach, since it is logical module, but your deployment requires two separate Solaris packages. In the Mojos configuration you would just need to declare the groupIds of the custom packages e.g. like: customGroupIds customGroupIdmy.foo.id/customGroupId /customGroupIds You are right - this way ensures that it will work in further releases and is not missusing the POM. But it is quite greedy: build plugins plugin groupIdmy.foo/groupId artifactIdmojo-hack/artifactId executions execution goalhack-dependencies/goal configuration customGroupIds customGroupIdmy.foo.id/customGroupId /customGroupIds /configuration /execution /executions /plugin /plugins /build What I like more about my approach is that it is more natural and easier to maintain if I express this as an exclusion in the dependencies. It is actually not a plugin specific thing but really a configuration to express the modules dependencies. What I wanted to point out is that I have a need to express dependencies in a way that is NOT yet supported with maven. I use maven for open-source as well as for business. And in business it is a very common need to build packages in a way as I described. Now the maven community could think about supporting such exclusions in the core dependency management or come to the point that this is a too specific situation and should be solved as you pointed out. But then the next question is, if this specific solution shouldn't be available in the maven-dependency-plugin. and take that list as exclusion for the the EXT package and as inclusion for your CUST package. BTW: the plexus/components.xml was really hard to figure out. Is there any documentation that I missed? Should I write a mini xdoc about what I figured out about how to create your own packaging? Are you interested in a maven-solaris-package-plugin ? If there is a real solution for my HACK I would love to donate the plugin to maven. I doubt that anybody is against additional docs :) I'll write an xdoc in the next weeks and put it into jira. But I think I will not include my Hack and suggest to use the maven-dependency-plugin. But then I have to make the ant stuff to be the plugin itself. I haven't checked out yet, if it is possible to have an ant script as maven2 plugin. - Jörg Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEtqMrmPuec2Dcv/8RArH1AJ455eUvwFb+buwLZouaKduXKcZFugCfbFiJ iaD08di7zanQ8CRTA/s5TUY= =ZZ3R -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Default Filtered Resources Directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brett Porter wrote: I think this has already been suggested in JIRA, but if not it is worth adding. I only found issues that are slightly related, but not yet the same thing. I'll put it into JIRA on monday... - Brett Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEtqOOmPuec2Dcv/8RAq8zAJ0VWktvSYlNBK9RymBv6w9VUsKiLACglnmc ju5DTW8e+ZJlW+WxucNPIqw= =FA5d -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Layout of multiproject projects
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Edwin,
Edwin Punzalan wrote:
The TREE layout is recommended... the plugins are laid-out flat bec they
are all plugins which means they all have a single parent. No use for a
sub-parent for now... but there have been talks of categorizing the
plugins which maybe a good cause for sub-parents with their own children.
Thanks for this information. Maybe there should be a mini-guide about
multi-project layout...
But strange - maybe I did something wrong or started on a too early version of
maven2 (plugins), but the source-repository report did not work right with TREE
layout that time.
Anyways the user should be quite free to layout his project.
I could also think about a third example:
trunk/
trunk/foo-project/project/pom.xml
trunk/foo-project/children/foo-project-util/project/pom.xml
trunk/foo-project/children/foo-project-service/project/pom.xml
trunk/foo-project/children/foo-project-service/children/foo-project-service-core/project/pom.xml
trunk/foo-project/children/foo-project-service/children/foo-project-service-main/project/pom.xml
Now I think if maven could have an optional tag in the parent that overrides
the path to the parent project. The default would be ../ for TREE layout.
For the flat layout you can use ../${parent.artifactId}. In the crazy example
above, it would be ../../../project.
This would be the inverse of the modules path.
You might say that there is no need for this. But then you never had a parent
pom with an ant-script or complex build rules inside and you got totally
crazy from the extra mvn -N install call in the parent project (that why I
discovered -N).
So if maven has a way to find the parent pom.xml locally and it is there and has
the specified version it could be read insted of taking it from the repository.
Anyways for the problems that some of the plugins have with the
different layouts: I think that all information is already there in a reactor
build and the modules directives give all information needed for
source-repository report, maven-release-plugin, etc.
Thinks that are not working properly are just bugs.
Regards
Jörg
p.s. sorry for top-posting ;)
Joerg Hohwiller wrote:
Hi there,
I have a complex maven project that goes down to 3 levels of POM
inheritance (=
it has sub-sub-projects).
I am not really sure about what the suggested layout is:
TREE:
trunk/
trunk/foo-project/pom.xml
trunk/foo-project/foo-project-util/pom.xml
trunk/foo-project/foo-project-service/pom.xml
trunk/foo-project/foo-project-service/foo-project-service-core/pom.xml
trunk/foo-project/foo-project-service/foo-project-service-main/pom.xml
or
FLAT:
trunk/
trunk/foo-project/pom.xml
trunk/foo-project-util/pom.xml
trunk/foo-project-service/pom.xml
trunk/foo-project-service-core/pom.xml
trunk/foo-project-service-main/pom.xml
As it seems by most plugins the FLAT layout is required for them to
work.
On the other hand some parts of maven seem to expect the TREE layout
(e.g.
parent POMs are sometimes looked up at ../pom.xml).
I personally prefer the TREE variant. Especially if someone only
wants to
checkout and work on a sub-project this makes it way easier!
But because I got into heavy trouble with maven I changed to the
FLAT variant
(what caused a lot of stupid work).
I could not find any offical documentation about this toppic.
My personal oppinion is that maven should support both ways (without
heavy
customization).
The problem is that there are lots of plugins heavily involved in this
issue
(maven-release-plugin, all the reports such as the source repository,
etc) and
the maven-core itself.
So what do you think about this one?
Take care
Jörg
- -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEtqg5mPuec2Dcv/8RAnHCAJ0c2Mv08dkeopwrgWPLK/D8fEzXMgCeOtJQ
GWVzazQuhI9TJn2nW/rScGI=
=gPnR
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Default Filtered Resources Directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I read about the Super-POM at: http://maven.apache.org/guides/introduction/introduction-to-the-pom.html My question is now, if it was possible to add an additional resources directory that is filtered. It would not hurt anybody if he does not use it, but it would be very handy to have it as default. My suggestion would be to add: resource directorysrc/main/templates/directory filteringtrue/filtering /resource You could also name it filtered-resources or whatever. I dont realy care about the name of the directory - I just would love to have a standard defined by maven. You can also add the same directive for src/test. - From your examples (http://maven.apache.org/guides/getting-started/index.html) people can get the idea to change the resources directory to be filtered. I actually do NOT think that this is a good idea. My problem is that I have to override the complete resources directive to add this AND the maven philosophy is to have a standard directory layout and the need for very little configuration. Wouldn't this be a good idea? Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEtW5DmPuec2Dcv/8RAoWHAJ4g3G/CKeyfcAiHCqkQPmTbsuRudACfXssO sU1NmJjl8BFnBOSMgROz1hY= =HD+O -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
maven dependecies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, Maven2 really rocks! I figured out a way to build a plugin that allows solaris as packaging and builds a solaris package for a maven project. Therefore I add the complete static content of the package to the main/resources. Further I have a filtered resources directory where I add files with variables to be replaced during the build (pkginfo, prototype-template, and configuration content of the package). As compile phase I add the dependent artifacts to the package at a configurable directory. Finally I build the solaris package with an ant script using the maven-antrun-plugin. Now I have two questions/suggestions/...? 1. The maven resources plugin does NOT copy empty directories (as it seems to me). Now I am so happy with subversion that I can have empty directories and also be able to maintain them. In this case I still have to add the good olds ignore.txt files to empty directories so they are included in the package. Is there a way to make the maven resources plugin to copy empty directories? 2. To add the dependencies to the package I added the dependency on my maven software modules and used the maven-dependency-plugin to copy the artifacts. Now I came into trouble with maintainance because I want to have my software split in multiple packages. One is containing the thirdparty stuff (lest call it PKG-EXT) and another I containing my custom code (PKG-CUST). Therefore I would need to have the following dependency in PKG-EXT: dependency groupIdmy.foo.id/groupId artifactIdmy-master-app/artifactId version1.0/version excludes exclude groupIdmy.foo.id/groupId artifactIdmy-utils/artifactId /exclude exclude groupIdmy.foo.id/groupId artifactIdmy-core/artifactId /exclude exclude groupIdmy.foo.id/groupId artifactIdmy-master-app/artifactId /exclude ... /excludes /dependency Besides the fact that it does NOT work to exclude the dependency itself, I would need to maintain this whenever the dependencies of my modules change. Additionally I would need to add all the excluded dependencies including their versions as dependencies to PKG-CUST. Now here is what I did (as a brute HACK) to solve my problem: I wrote a maven plugin (the MOJO stuff and maven APIs are really cool - easy to get quick results) that acts as the maven-depdencies-plugin but allows to have * as artifactId in an the exclusion. For the PKG-CUST package I use the plugin with inverted logic. Surprisingly you are still here reading. My questions are now: Will maven support something like this by default one day? If not will my HACK still work in further releases or can it happen that the verification gets updated and my pom becomes invalid because * is no vaild artifactId anymore? Thank you for reading this. I hope to get an answer. BTW: the plexus/components.xml was really hard to figure out. Is there any documentation that I missed? Should I write a mini xdoc about what I figured out about how to create your own packaging? Are you interested in a maven-solaris-package-plugin ? If there is a real solution for my HACK I would love to donate the plugin to maven. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEtXVHmPuec2Dcv/8RAueyAJ0YL1fw2yyyDsQu/my62slM6j6b0gCfdG9T TwwchCw+fVe6Yl+BQj0gZEA= =AJ7l -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Layout of multiproject projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I have a complex maven project that goes down to 3 levels of POM inheritance (= it has sub-sub-projects). I am not really sure about what the suggested layout is: TREE: trunk/ trunk/foo-project/pom.xml trunk/foo-project/foo-project-util/pom.xml trunk/foo-project/foo-project-service/pom.xml trunk/foo-project/foo-project-service/foo-project-service-core/pom.xml trunk/foo-project/foo-project-service/foo-project-service-main/pom.xml or FLAT: trunk/ trunk/foo-project/pom.xml trunk/foo-project-util/pom.xml trunk/foo-project-service/pom.xml trunk/foo-project-service-core/pom.xml trunk/foo-project-service-main/pom.xml As it seems by most plugins the FLAT layout is required for them to work. On the other hand some parts of maven seem to expect the TREE layout (e.g. parent POMs are sometimes looked up at ../pom.xml). I personally prefer the TREE variant. Especially if someone only wants to checkout and work on a sub-project this makes it way easier! But because I got into heavy trouble with maven I changed to the FLAT variant (what caused a lot of stupid work). I could not find any offical documentation about this toppic. My personal oppinion is that maven should support both ways (without heavy customization). The problem is that there are lots of plugins heavily involved in this issue (maven-release-plugin, all the reports such as the source repository, etc) and the maven-core itself. So what do you think about this one? Take care Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFEtXmnmPuec2Dcv/8RAro1AJjOTcE8zTE0+9zIasxYo6MRmuX6AJ9NgmIZ P98hl7J0gp8mRI3rHl4SEA== =g9rO -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ibibilio.org / maven.org down?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, currently I can not access www.ibiblio.org while sf.net, codehause.org, etc. is accessable without problems. Is there a temporary downtime? Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD3nivmPuec2Dcv/8RArX3AJ9hcWJoTxS6kzdJGOObVd5cE5PZtgCgmiTc KGJoQ+wgO3vw+u/FKsRkTyE= =7Bmk -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: optional dependencies was: [m2] POM inheritance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, Joerg Hohwiller wrote: Hello Brett, Brett Porter wrote: We've so far opted not to do this (basically an optional dependency) as it can encourage poorly specified poms to stay that way. Basically by saying this you are saying to those depending on you you may need tis jar at some point, but I can't tell you when. That's going to manifest in a class cast exception. It really is a dependency, and instead we allow the dependee to exclude the ones it knows it doesn't need. This is more tedious though, and I'm not currently certain whether it is better to allow optinoal dependencies to aid in this. Well if we make the example (commons-logging) more abstract we can think of a project providing a facade to some functionalitiy provided by various exisiting implementations (e.g. could also be a facade for GUI toolkits that allows Swing and SWT as backend). In that case you would have a more abstract dependency where one can choose. If that would be expressed in the POM as dependency group there could also be a default choice if not explicitly choosen by the aggregating project. But actually the more I think about, it may be the best and simplest approach to have a project just for the API and general code and a subproject for each backend implementation defining the dependencies to the real implementation. In the aggregating project you have a dependency on the API and choose the implementation by another dependency. So all I am saying is: you're right and maven(2) enforces structuring your projects, which is good :) Actually I got totally lost in jarkarta-commons and othe projects before getting into maven. But now from the commons-logging point of view I want to raise this issue again: If JCL would have the API as top-level project and a sub-project for each bridge-implementation (log4j1.2, log4j1.3, jdk1.4-logger, logkit, avalon, etc.) this would cause: 1. ugly maintainence of the project 2. a jar for each bridge-implementation I think one could live with 1. Especially there is a general problem because of the dependency on log4j in two different version - this forces to splitt off in sub-projects if maven is used at all for the build. But for 2. there should be a way to build a jar in the top-level project that includes all code-output compiled in the sub-projects. Is that making sense for you or is this already targeted by m2? Do you see a better solution? BTW. I have seen this issue for aggregated javadocs in maven1 discussions a long time ago. Is that solved in m2? [cut] Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTDDXmPuec2Dcv/8RAhvNAJ9rHaZuCa+pduDOfZ5eE9sgG/mMIgCghJ5u BWBIw970xrSMXMnetOQmJFg= =EFwJ -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [me] Setting up the project in my IDE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Trygve Laugstøl wrote: On Wed, Aug 10, 2005 at 06:49:40PM +0200, Joerg Hohwiller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I got a little lost in jakarta-commons since my getting involved? thread, but finally I checked out the complete m2 thing. You tailered your components quite small - which (usually) leads to a gread design. Anyways I am little frustrated setting all this up in my JAVA IDE (eclipse). I tried the according plugin to generate the IDE config but did not succeed since the toplevel POM seems to be broken. Broken how? Not all of the modules are in the default modules collection so you might have to go into some sub directories to be able to generate the project files for all Maven 2 artifacts. [EMAIL PROTECTED]:~/projects/maven2$ m2 eclipse:eclipse [INFO] - [INFO] BUILD FAILURE [INFO] - [INFO] Reason: Failed to parse model from file '/home/joerg/projects/maven2/pom.xml'. Error: 'TEXT must be immediately followed by END_TAG and not START_TAG (position: START_TAG seen ...snapshotRepository\n id... @121:11) ' [INFO] - [INFO] Total time: 1 second [INFO] Finished at: Wed Aug 10 19:16:09 CEST 2005 [INFO] Final Memory: 1M/2M [INFO] - [EMAIL PROTECTED]:~/projects/maven2$ cd maven-artifact [EMAIL PROTECTED]:~/projects/maven2/maven-artifact$ m2 eclipse:eclipse [INFO] maven: using locally installed snapshot [INFO] - [INFO] BUILD FAILURE [INFO] - [INFO] Reason: Failed to parse model from file '/home/joerg/.m2/repository/org/apache/maven/maven/2.0-beta-1-SNAPSHOT/maven-2.0-beta-1-SNAPSHOT.pom'. Error: 'TEXT must be immediately followed by END_TAG and not START_TAG (position: START_TAG seen ...snapshotRepository\n id... @121:11) ' [INFO] - [INFO] Total time: 1 second [INFO] Finished at: Wed Aug 10 19:16:34 CEST 2005 [INFO] Final Memory: 1M/2M [INFO] - So I need a toplevel POM that is NOT broken. Do you have any suggestions (or maybe a developers manual :) ) to make my start a little easier? I added some how to develop Maven 2 earlier today, but as the site it not deployed yet you'll have to read it from the Subversion repository[1]. Not that that make it any harder to read, it's APT after all ;) As this is only a small start any contributions or just plain notes you're takin while getting into Maven 2 development would be appreciated. [1]: https://svn.apache.org/repos/asf/maven/components/trunk/maven-site/src/site/apt/developers/development-guide.apt Thanks. But its more about general support and svn usage. I will contribute something if I am through with this (and its not the setup every single subproject in eclipse by hand solution). -- Trygve Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+jd9mPuec2Dcv/8RAvvqAJ0SakMd63DkG4af2d3Fut2eY4oY7wCfT2r3 d2Pwke9cRcBmk17UIJRYEcE= =QDEX -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [me] Setting up the project in my IDE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Trygve, So I need a toplevel POM that is NOT broken. You need to use the latest Maven 2 from trunk to be able to build Maven 2. Read up on how to build Maven 2 here[1]. [1]: http://maven.apache.org/maven2/building.html I DO use the latest! [EMAIL PROTECTED]:~/projects/maven2$ cat .svn/entries | grep url url=http://svn.apache.org/repos/asf/maven/components/trunk; [EMAIL PROTECTED]:~/projects/maven2$ svn update Revision 231289. [EMAIL PROTECTED]:~/projects/maven2$ m2 eclipse:eclipse [INFO] - [INFO] BUILD FAILURE [INFO] - [INFO] Reason: Failed to parse model from file '/home/joerg/projects/maven2/pom.xml'. Error: 'TEXT must be immediately followed by END_TAG and not START_TAG (position: START_TAG seen ...snapshotRepository\n id... @121:11) ' [INFO] - [INFO] Total time: 1 second [INFO] Finished at: Wed Aug 10 20:24:44 CEST 2005 [INFO] Final Memory: 1M/2M [INFO] - Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+kbImPuec2Dcv/8RAga6AJ9Oq8x6zdArrRDkihPBEZEJZauAUACfaxtO cRV2T5cCHaWugHIaGczZwp4= =EyQv -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [me] Setting up the project in my IDE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Trygve Laugstøl wrote: On Wed, Aug 10, 2005 at 08:26:16PM +0200, Joerg Hohwiller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Trygve, So I need a toplevel POM that is NOT broken. You need to use the latest Maven 2 from trunk to be able to build Maven 2. Read up on how to build Maven 2 here[1]. [1]: http://maven.apache.org/maven2/building.html I DO use the latest! [snip] Pasting lots of output is not the most effective way of getting help. I did not mean to spam you with my console output. I just thought the few lines would say very precises on which SVN_ROOT and revision I am working and that I still have the problem with the latest head revision. Make sure that the version you installed is the one that you are actually using, look in PATH and make sure that M2_HOME points to the right location. Verify that are running the correct version by running $ m2 -version Mine outputs Maven version: 2.0-beta-1-SNAPSHOT. Yep, you gessed it. The problem is that I did not read everything completely. Sorry for that. So since I have beta-1 instead of alpha-3 it works fine now. -- Trygve Thank you Jörg p.s.: In case anyone cares: There is a very clear suggestion for commandline arguments from GNU that is used by most linux and other programms. So for full word triggers it should be -- as prefix. This allows combining single letter options without clashing the full-wort options. So -h or --help. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC+miSmPuec2Dcv/8RApGHAKCJJDf5Che0hncv7XEP8GOvvrGFDgCfWAY0 lyHfdo47Yf/CJRGTgYmy9ZI= =p8Mm -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: optional dependencies was: [m2] POM inheritance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Brett, Brett Porter wrote: We've so far opted not to do this (basically an optional dependency) as it can encourage poorly specified poms to stay that way. Basically by saying this you are saying to those depending on you you may need tis jar at some point, but I can't tell you when. That's going to manifest in a class cast exception. It really is a dependency, and instead we allow the dependee to exclude the ones it knows it doesn't need. This is more tedious though, and I'm not currently certain whether it is better to allow optinoal dependencies to aid in this. Well if we make the example (commons-logging) more abstract we can think of a project providing a facade to some functionalitiy provided by various exisiting implementations (e.g. could also be a facade for GUI toolkits that allows Swing and SWT as backend). In that case you would have a more abstract dependency where one can choose. If that would be expressed in the POM as dependency group there could also be a default choice if not explicitly choosen by the aggregating project. But actually the more I think about, it may be the best and simplest approach to have a project just for the API and general code and a subproject for each backend implementation defining the dependencies to the real implementation. In the aggregating project you have a dependency on the API and choose the implementation by another dependency. So all I am saying is: you're right and maven(2) enforces structuring your projects, which is good :) - Brett Joerg Hohwiller wrote: Hi there, John Casey wrote: try adding inherittrue/inherit to the plugin definition at the top level...I can't remember whether the compiler plugin inherits by default or not (my suspicions are not). Not about POM inheritance but about dependency inheritance (transitive dependencies): Can I also put inheritfalse/inherit to a dependency definition so it will not be inherited. E.g. if commons-logging does not want to carry out all of their supported implementations? Regards Jörg Thanks Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC97EbmPuec2Dcv/8RAloPAKCVq41//SAgOqGakWlJ40TWP1jsFQCeOM7y bgYSYkwBXeGPr9Jfv2PkeoE= =bkou -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IoC (was Re: [m2] getting involved?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Thomas, Thomas Van de Velde wrote: BTW - I like plexus. Haven't noticed the project before. I had used avalon and had a look at pico+nano before. Plexus seems to be powerfull like avalon containers but less invasive (like the spring-framework). Maybe I'll use that in my project. Would you again decide for plexus if you'd choose now? In what way would Spring be more invasive than Plexus? None. That is what I was saying: Plexuse seems to be less invasive than avalon. And shares this ability with spring. My issue with the Plexus container is that it is completely unknown to most developers, that there are no books and hardly any documentation on the site. I assume there must be good reasons for starting yet another IoC container (Can somebody elaborate on those reasons?) For me the reason was that the Avalon API is inacceptable for me because I am bound to it. If I would later switch to spring or anything else, I would need to rewrite a lot of my code. And the message on the avalon homepage says a clear language. So I looked at spring and it seemed that it solves that issue but on the other hand the bean-factory approach is a little too low-level for me. I have to do way too much just to get simple things done (e.g. injecting a component-specific logger) and the configuration is xml but what you are doing is not configuration but programming. So besides I looked at various other solutions but havent found anything acceptable so far. So I started my own Container. As I pointed out in my mail: I found plexus and it looks good. There is hardly no documentation and if you just start on the homepage of plexus you will never even come to the point deciding to use it. Maybe I'll drop my own container and switch to plexus - time will show. But in may case the requirements for the container are so simple that it might be easier to develop my own than understanding plexus :) Anyways I started an experiment by writing some sort of API or better specification for component descriptoring that could be understood by any container-framework so components could be developed completely container independent - for those who are interesed: http://m-m-m.sourceforge.net/container/javadoc/ http://m-m-m.sourceforge.net/container/container.jar I would love to hear comments from your point of view since you have a lot more requirements for the container. So would you say that just some things are missing in the suggested API or would you say that the complete approach would be inacceptable for you / for plexus / for whatever thing and reason. Take care Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC9RtvmPuec2Dcv/8RAskQAKCAO6qbi6nP4pLpMkVlRVImHF+CEACdHR7t Sh+dq7eixO5g1g1IewMDUzA= =2s+b -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] POM inheritance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, John Casey wrote: try adding inherittrue/inherit to the plugin definition at the top level...I can't remember whether the compiler plugin inherits by default or not (my suspicions are not). Not about POM inheritance but about dependency inheritance (transitive dependencies): Can I also put inheritfalse/inherit to a dependency definition so it will not be inherited. E.g. if commons-logging does not want to carry out all of their supported implementations? Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC9R4ImPuec2Dcv/8RAgp0AJ9IAb0yV2fqNeBwt5WgFJ0Tr734aQCfd6Dy TEC4U7jV3ldvW0Wg1TDdn24= =PKUr -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
