Re: Maven Site Plugin
On 15 Dec 06, at 2:35 PM 15 Dec 06, Wendy Smoak wrote: On 12/15/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: I'll work with you today if you have time and we'll try out the struts site. It ran with no errors on the Struts 1.x and top-level sites, but I won't have time to make sure everything looks okay until tomorrow afternoon. Sure, no problem. I'll try it out some more and get others too and we'll call a vote on Monday. Jason. -- Wendy - 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: [m2] Dev help needed: Should multiple repositories be able to host an artifact, potentially with different versions
On 12/16/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote: Thanks Kenney, - colleagues will automatically get the snapshot version of the plugin, but due to a a bug in maven 2.0.4 they could end up with the wrong plugin in the reactor. For instance: mvn o.a.m.p:maven-assembly-plugin:2.3-SNAPSHOT:directory will first list the 2.3 version, and in the lifecycle fork maven will resolve to 2.2. [del] So, basically: do NOT specify the maven plugin snapshot repo anywhere, but only an internal one, and manually manage what snapshot plugins are hosted there. It serves as an override of the non-snapshot central repo. We are finding that this approach isn't working when our colleagues do not have the new artifact. This is because maven loops through all repositories to merge the metadata from pluginRepository company.repo and central to correctly find the new version but then also updates the metadata to use the current repository in the loop, so it sets the repo to company.repo and then central, so when the wagon attempts to get the artifact it tries to contact central which of course does not have this artifact. This is the problem we are attempting to resolve, at least two other people have the same problem. When I wrote the wiki guide I never noticed this problem because I have mvnproxy in the way and mvnproxy was aggregating both company.repo and central, so even though maven was contacting central, mvnproxy would be returning the artifact from company.repo for me. The use of a snapshot repository does not affect this feature of maven. I'm fairly confident that what I am describing is correct as I've step debugged through artifact resolution to replicate what others were seeing once I turned off mvnproxy. I'm think this is working for you at your site because 1) you are using snapshot versions and not releases 2) you do not include any external snapshot repositories and hence there is only ever one repository that mathces your artifact and thus never hit this problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Site Plugin
On 12/15/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: I'll work with you today if you have time and we'll try out the struts site. It ran with no errors on the Struts 1.x and top-level sites, but I won't have time to make sure everything looks okay until tomorrow afternoon. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r487615 - in /maven/archiva/trunk/maven-meeper/src/site: fml/ fml/faq.fml fr/ fr/apt/ fr/apt/format.apt fr/apt/index.apt fr/fml/ fr/fml/faq.fml fr/xdoc/ fr/xdoc/xdoc.xml site.xml site_
*cough* with slightly verbose content from the site archetype On 12/15/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: On 15 Dec 06, at 1:57 PM 15 Dec 06, Emmanuel Venisse wrote: > What are all these files? > Site for administering the repository. Jason. > Emmanuel > > [EMAIL PROTECTED] a écrit : >> Author: jmcconnell >> Date: Fri Dec 15 10:39:19 2006 >> New Revision: 487615 >> URL: http://svn.apache.org/viewvc?view=rev&rev=487615 >> Log: >> initial site for meeper and a brief howto sync up central >> Added: >> maven/archiva/trunk/maven-meeper/src/site/fml/ >> maven/archiva/trunk/maven-meeper/src/site/fml/faq.fml >> maven/archiva/trunk/maven-meeper/src/site/fr/ >> maven/archiva/trunk/maven-meeper/src/site/fr/apt/ >> maven/archiva/trunk/maven-meeper/src/site/fr/apt/format.apt >> maven/archiva/trunk/maven-meeper/src/site/fr/apt/index.apt >> maven/archiva/trunk/maven-meeper/src/site/fr/fml/ >> maven/archiva/trunk/maven-meeper/src/site/fr/fml/faq.fml >> maven/archiva/trunk/maven-meeper/src/site/fr/xdoc/ >> maven/archiva/trunk/maven-meeper/src/site/fr/xdoc/xdoc.xml >> maven/archiva/trunk/maven-meeper/src/site/site.xml >> maven/archiva/trunk/maven-meeper/src/site/site_fr.xml >> maven/archiva/trunk/maven-meeper/src/site/xdoc/ >> maven/archiva/trunk/maven-meeper/src/site/xdoc/xdoc.xml >> Added: maven/archiva/trunk/maven-meeper/src/site/fml/faq.fml >> URL: http://svn.apache.org/viewvc/maven/archiva/trunk/maven-meeper/ >> src/site/fml/faq.fml?view=auto&rev=487615 >> = >> = >> --- maven/archiva/trunk/maven-meeper/src/site/fml/faq.fml (added) >> +++ maven/archiva/trunk/maven-meeper/src/site/fml/faq.fml Fri Dec >> 15 10:39:19 2006 >> @@ -0,0 +1,25 @@ >> + >> + >> + >> + >> + Where did Maven come from? >> + >> + >> + Maven was created by a group of software developers who >> were tired >> + of wasting their time fiddling around with builds and >> wanted to get >> + down to brass tacks and actually develop software! >> + >> + >> + >> + >> + Why is maven so wildly popular? >> + >> + >> + Maven saves you so much time in your software >> development efforts that >> + you will have time to learn a second language, relax >> ten hours a >> + day, and train for that marathon you've always wanted >> to run! >> + >> + >> + >> + >> + >> Added: maven/archiva/trunk/maven-meeper/src/site/fr/apt/format.apt >> URL: http://svn.apache.org/viewvc/maven/archiva/trunk/maven-meeper/ >> src/site/fr/apt/format.apt?view=auto&rev=487615 >> = >> = >> --- maven/archiva/trunk/maven-meeper/src/site/fr/apt/format.apt >> (added) >> +++ maven/archiva/trunk/maven-meeper/src/site/fr/apt/format.apt >> Fri Dec 15 10:39:19 2006 >> @@ -0,0 +1,596 @@ >> + >> +Le format APT >> +~ >> + >> + Dans la section suivante, les bo?tes contenant du texte dans >> la police >> + de type machine ? ?crire sont des exemples de source APT. >> + >> +* Structure du document >> +~~~ >> + >> + A short APT document is contained in a single text file. A >> longer document >> + may be contained in a ordered list of text files. For instance, >> first text >> + file contains section 1, second text file contains section 2, >> and so on. >> + >> + [Note:] Splitting the APT document in several text files on >> a section >> + boundary is not mandatory. The split may occur >> anywhere. >> + However doing so is recommended because a text file >> containing a >> + section is by itself a valid APT document. >> + >> + A file contains a sequence of paragraphs and ``displays'' (non >> paragraphs >> + such as tables) separated by open lines. >> + >> + A paragraph is simply a sequence of consecutive text lines. >> + >> + >> + >> + >> + First line of first paragraph. >> + Second line of first paragraph. >> + Third line of first paragraph. >> + + Line 1 of paragraph 2 (separated from first paragraph by an >> open line). >> + Line 2 of paragraph 2. >> + >> + >> + >> + >> + The indentation of the first line of a paragraph is the main >> method used by >> + an APT processor to recognize the type of the paragraph. For >> example, a >> + section title must not be indented at all. >> + >> + A ``plain'' paragraph must be indented by a certain amount of >> space. For >> + example, a plain paragraph which is not contained in a list may >> be indented >> + by two spaces. >> + >> ++-+ >> +My section title (not indented). >> + >> + My paragraph first line (indented by 2 spaces)
Re: downloading eclipse runtime binary or RCP delta pack
Bhupendra Bhardwaj wrote: The maven repository doesn't have the eclipse swt plugins for all platforms. I have few questions, can those be answered please if possible- - Can I download the eclipse runtime binary or any zip/tar from http://download.eclipse.org/eclipse/downloads/drops/R-3.2.1-200609210945/. If yes, then how? I am currently in the process of trying to solve this problem. Although the latest eclipse jars are not (yet) available in a maven repository, the 2.3-SNAPSHOT maven-eclipse-plugin has a goal eclipse:make-artifacts that, given a directory containing an eclipse installation, will import all the eclipse jars into your local repository, complete with dependency information. It works very well. You can point the maven-eclipse-plugin at the deltapack, and those jars can be imported as well. - how can I assemble the RCP for different platform using maven? Is it profiles I need to use in assembling or there is some other or better way. That is my next task - the maven-pde-plugin seems the most likely solution, however I have not yet found a way to produce an eclipse RCP app for multiple platforms using this method, yet. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r487615 - in /maven/archiva/trunk/maven-meeper/src/site: fml/ fml/faq.fml fr/ fr/apt/ fr/apt/format.apt fr/apt/index.apt fr/fml/ fr/fml/faq.fml fr/xdoc/ fr/xdoc/xdoc.xml site.xml site_
On 15 Dec 06, at 1:57 PM 15 Dec 06, Emmanuel Venisse wrote: What are all these files? Site for administering the repository. Jason. Emmanuel [EMAIL PROTECTED] a écrit : Author: jmcconnell Date: Fri Dec 15 10:39:19 2006 New Revision: 487615 URL: http://svn.apache.org/viewvc?view=rev&rev=487615 Log: initial site for meeper and a brief howto sync up central Added: maven/archiva/trunk/maven-meeper/src/site/fml/ maven/archiva/trunk/maven-meeper/src/site/fml/faq.fml maven/archiva/trunk/maven-meeper/src/site/fr/ maven/archiva/trunk/maven-meeper/src/site/fr/apt/ maven/archiva/trunk/maven-meeper/src/site/fr/apt/format.apt maven/archiva/trunk/maven-meeper/src/site/fr/apt/index.apt maven/archiva/trunk/maven-meeper/src/site/fr/fml/ maven/archiva/trunk/maven-meeper/src/site/fr/fml/faq.fml maven/archiva/trunk/maven-meeper/src/site/fr/xdoc/ maven/archiva/trunk/maven-meeper/src/site/fr/xdoc/xdoc.xml maven/archiva/trunk/maven-meeper/src/site/site.xml maven/archiva/trunk/maven-meeper/src/site/site_fr.xml maven/archiva/trunk/maven-meeper/src/site/xdoc/ maven/archiva/trunk/maven-meeper/src/site/xdoc/xdoc.xml Added: maven/archiva/trunk/maven-meeper/src/site/fml/faq.fml URL: http://svn.apache.org/viewvc/maven/archiva/trunk/maven-meeper/ src/site/fml/faq.fml?view=auto&rev=487615 = = --- maven/archiva/trunk/maven-meeper/src/site/fml/faq.fml (added) +++ maven/archiva/trunk/maven-meeper/src/site/fml/faq.fml Fri Dec 15 10:39:19 2006 @@ -0,0 +1,25 @@ + + + + + Where did Maven come from? + + + Maven was created by a group of software developers who were tired + of wasting their time fiddling around with builds and wanted to get + down to brass tacks and actually develop software! + + + + + Why is maven so wildly popular? + + + Maven saves you so much time in your software development efforts that + you will have time to learn a second language, relax ten hours a + day, and train for that marathon you've always wanted to run! + + + + + Added: maven/archiva/trunk/maven-meeper/src/site/fr/apt/format.apt URL: http://svn.apache.org/viewvc/maven/archiva/trunk/maven-meeper/ src/site/fr/apt/format.apt?view=auto&rev=487615 = = --- maven/archiva/trunk/maven-meeper/src/site/fr/apt/format.apt (added) +++ maven/archiva/trunk/maven-meeper/src/site/fr/apt/format.apt Fri Dec 15 10:39:19 2006 @@ -0,0 +1,596 @@ + +Le format APT +~ + + Dans la section suivante, les bo?tes contenant du texte dans la police + de type machine ? ?crire sont des exemples de source APT. + +* Structure du document +~~~ + + A short APT document is contained in a single text file. A longer document + may be contained in a ordered list of text files. For instance, first text + file contains section 1, second text file contains section 2, and so on. + + [Note:] Splitting the APT document in several text files on a section + boundary is not mandatory. The split may occur anywhere. + However doing so is recommended because a text file containing a + section is by itself a valid APT document. + + A file contains a sequence of paragraphs and ``displays'' (non paragraphs + such as tables) separated by open lines. + + A paragraph is simply a sequence of consecutive text lines. + + + + + First line of first paragraph. + Second line of first paragraph. + Third line of first paragraph. + + Line 1 of paragraph 2 (separated from first paragraph by an open line). + Line 2 of paragraph 2. + + + + + The indentation of the first line of a paragraph is the main method used by + an APT processor to recognize the type of the paragraph. For example, a + section title must not be indented at all. + + A ``plain'' paragraph must be indented by a certain amount of space. For + example, a plain paragraph which is not contained in a list may be indented + by two spaces. + ++-+ +My section title (not indented). + + My paragraph first line (indented by 2 spaces). ++-+ + + Indentation is not rigid. Any amount of space will do. You don't even need + to use a consistent indentation all over your document. What really matters + for an APT processor is whether the paragraph is not indented at all or, + when inside a list, whether a paragraph is more or less indented than the + first item of the list (more about this later). + ++
Re: svn commit: r487615 - in /maven/archiva/trunk/maven-meeper/src/site: fml/ fml/faq.fml fr/ fr/apt/ fr/apt/format.apt fr/apt/index.apt fr/fml/ fr/fml/faq.fml fr/xdoc/ fr/xdoc/xdoc.xml site.xml site_
What are all these files? Emmanuel [EMAIL PROTECTED] a écrit : Author: jmcconnell Date: Fri Dec 15 10:39:19 2006 New Revision: 487615 URL: http://svn.apache.org/viewvc?view=rev&rev=487615 Log: initial site for meeper and a brief howto sync up central Added: maven/archiva/trunk/maven-meeper/src/site/fml/ maven/archiva/trunk/maven-meeper/src/site/fml/faq.fml maven/archiva/trunk/maven-meeper/src/site/fr/ maven/archiva/trunk/maven-meeper/src/site/fr/apt/ maven/archiva/trunk/maven-meeper/src/site/fr/apt/format.apt maven/archiva/trunk/maven-meeper/src/site/fr/apt/index.apt maven/archiva/trunk/maven-meeper/src/site/fr/fml/ maven/archiva/trunk/maven-meeper/src/site/fr/fml/faq.fml maven/archiva/trunk/maven-meeper/src/site/fr/xdoc/ maven/archiva/trunk/maven-meeper/src/site/fr/xdoc/xdoc.xml maven/archiva/trunk/maven-meeper/src/site/site.xml maven/archiva/trunk/maven-meeper/src/site/site_fr.xml maven/archiva/trunk/maven-meeper/src/site/xdoc/ maven/archiva/trunk/maven-meeper/src/site/xdoc/xdoc.xml Added: maven/archiva/trunk/maven-meeper/src/site/fml/faq.fml URL: http://svn.apache.org/viewvc/maven/archiva/trunk/maven-meeper/src/site/fml/faq.fml?view=auto&rev=487615 == --- maven/archiva/trunk/maven-meeper/src/site/fml/faq.fml (added) +++ maven/archiva/trunk/maven-meeper/src/site/fml/faq.fml Fri Dec 15 10:39:19 2006 @@ -0,0 +1,25 @@ + + + + + Where did Maven come from? + + + Maven was created by a group of software developers who were tired + of wasting their time fiddling around with builds and wanted to get + down to brass tacks and actually develop software! + + + + + Why is maven so wildly popular? + + + Maven saves you so much time in your software development efforts that + you will have time to learn a second language, relax ten hours a + day, and train for that marathon you've always wanted to run! + + + + + Added: maven/archiva/trunk/maven-meeper/src/site/fr/apt/format.apt URL: http://svn.apache.org/viewvc/maven/archiva/trunk/maven-meeper/src/site/fr/apt/format.apt?view=auto&rev=487615 == --- maven/archiva/trunk/maven-meeper/src/site/fr/apt/format.apt (added) +++ maven/archiva/trunk/maven-meeper/src/site/fr/apt/format.apt Fri Dec 15 10:39:19 2006 @@ -0,0 +1,596 @@ + +Le format APT +~ + + Dans la section suivante, les bo?tes contenant du texte dans la police + de type machine ? ?crire sont des exemples de source APT. + +* Structure du document +~~~ + + A short APT document is contained in a single text file. A longer document + may be contained in a ordered list of text files. For instance, first text + file contains section 1, second text file contains section 2, and so on. + + [Note:] Splitting the APT document in several text files on a section + boundary is not mandatory. The split may occur anywhere. + However doing so is recommended because a text file containing a + section is by itself a valid APT document. + + A file contains a sequence of paragraphs and ``displays'' (non paragraphs + such as tables) separated by open lines. + + A paragraph is simply a sequence of consecutive text lines. + +++ + First line of first paragraph. + Second line of first paragraph. + Third line of first paragraph. + + Line 1 of paragraph 2 (separated from first paragraph by an open line). + Line 2 of paragraph 2. +++ + + The indentation of the first line of a paragraph is the main method used by + an APT processor to recognize the type of the paragraph. For example, a + section title must not be indented at all. + + A ``plain'' paragraph must be indented by a certain amount of space. For + example, a plain paragraph which is not contained in a list may be indented + by two spaces. + ++-+ +My section title (not indented). + + My paragraph first line (indented by 2 spaces). ++-+ + + Indentation is not rigid. Any amount of space will do. You don't even need + to use a consistent indentation all over your document. What really matters + for an APT processor is whether the paragraph is not indented at all or, + when inside a list, whether a paragraph is more or less indented than the + first item of the list (more about this later). + ++---+ +First paragraph has its first line indented by four +spaces. Then the author did even bother to indent the +other lines of the paragraph. + +
Re: Maven and Fedora
Brett Porter wrote: On 15/12/2006, at 1:51 AM, Jason van Zyl wrote: On 14 Dec 06, at 9:46 AM 14 Dec 06, Carl Trieloff wrote: Suggestion: Would a good starting point be to maybe be to create a branch where some guys can work, and then we work item by item with the maven community. once we get an issue out the way, and agreed by maven team we merge the branch and start the next item? If they are Apache committers then they already have access to our sandbox. If they aren't then we can do it somewhere like the mojo project where we can give you access. So, to elaborate, Carl - as an Apache committer you are entitled to svn cp maven trunk into the sandbox as maven-fedora-integration or something similar and drive this, if you like. Brett, Thanks - I just wanted to make sure there was consensus on the list before we started that, else it could be a lot of work for nothing. Regards Carl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: downloading eclipse runtime binary or RCP delta pack
ant get task? On 12/15/06, Bhupendra Bhardwaj <[EMAIL PROTECTED]> wrote: Hi, This is regarding the eclipse plugin being developed in Apache Qpid project. The maven repository doesn't have the eclipse swt plugins for all platforms. I have few questions, can those be answered please if possible- - Can I download the eclipse runtime binary or any zip/tar from http://download.eclipse.org/eclipse/downloads/drops/R-3.2.1-200609210945/. If yes, then how? - how can I assemble the RCP for different platform using maven? Is it profiles I need to use in assembling or there is some other or better way. Thanks in advance Bhupendra
downloading eclipse runtime binary or RCP delta pack
Hi, This is regarding the eclipse plugin being developed in Apache Qpid project. The maven repository doesn't have the eclipse swt plugins for all platforms. I have few questions, can those be answered please if possible- - Can I download the eclipse runtime binary or any zip/tar from http://download.eclipse.org/eclipse/downloads/drops/R-3.2.1-200609210945/. If yes, then how? - how can I assemble the RCP for different platform using maven? Is it profiles I need to use in assembling or there is some other or better way. Thanks in advance Bhupendra
Re: The Future of the Release Process.
On Wednesday 13 December 2006 18:46, Joakim Erdfelt wrote: > Techniques: > 2) Staged release process > This process uses a staging workflow, there is no plugin for this > process (yet). > > The benefits of this process is that a real binary is being blessed. > This process also provides a way to resolve problems that occur > during the release process. > > It goes like this... >a) Call vote >b) Wait on approval. > .. >d) 'stage' release (occurs 1 or more times) >. >e) Wait on consensus from PMC for blessed artifacts. > * if not-blessed, make changes required and re-do step d. >f) 'bless' release (occurs once) I don't think this process is quite correct and is certainly not the process that is allowed to be used in the incubator. (a) and (b) basically boil down to: Start a discussion on the list about what needs to be in the release and make sure it's all documented in JIRA and nominate a release manager. When all items in JIRA are complete, the release manager will start producing release candidates. e) is the vote. You HAVE to vote on the staged binaries. You don't vote until the binaries are properly staged. If you have to restage the binaries (problem detected and fixed), you have to restart the vote. I know this is very different than the way the Maven team has been working. However, it's what we MUST do in the incubator. > Tools: > The following tools are to aide in this process. > maven-remote-resource-plugin (released) > This will copy the appropriate Apache process LICENSE.txt and > NOTICE.txt files into place for the released artifacts. The NOTICE.txt file generation is not working correctly yet.It doesn't produced a NOTICE file that would actually pass Apache legal review. I think the velocity template is OK, but the plugin itself isn't passing the required information to velocity. Thus, the "released" flag above should change to "alpha version available". Thanks! -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-ear-plugin and dependencies
On 12/15/06, Graham Leggett <[EMAIL PROTECTED]> wrote: On Thu, December 14, 2006 9:05 pm, Stephane Nicoll wrote: > This has been tackled a dozen of times and I am not sure it has > anything to do with the EAR plugin, at least if we follow the spec. If > I am wrong, please let me know. > > The valid way to bundle shared components/libs in a EAR is to define > the Class-Path entry of the manifest in EJB module(s) using the > component. It's certainly not by adding them in a module entry > in the application.xml even though some application servers support > this (JBoss namely). This where you make the spec compliant EJB jar by using the Class-Path manifest entry as Stephane stated. The "trick" that BEA and IBM looks similar to the spec for WAR but alas we do not have anything such thing for EAR files. All the things that various vendors are doing is a work around. This is something that should be added to the JEE spec to make it cleaner in a packaging as looking through EJB Jar files is nasty if one needs to debug. > The EAR plugin supports the APP-INF/lib weblogic's trick by using the > defaultJarBundleDir setting though. > > So I wouldn't say the EAR plugin has no dependency management features > at all, I don't even see the point actually :) Make sure that your > classpath entries got generated on the EJB side and it will just run > fine. Ok, then I'll put it this way: it has no dependency management features that are clearly enough documented :) If you create an ejb using the default ejb configuration, and then you add this ejb to an ear file again with a default configuration, maven goes through all the motions and creates what looks like a valid ear file. But this ear file refuses to load into Jboss (the dreaded NoClassDefFound exception). Is there a reason why a spec compliant ejb and ear can't be created by default by the ejb and ear plugins? I'm asking from ignorance - I don't have in depth knowledge of the internal structure of an ear file, that being maven's job to worry about this stuff for me. The only mention I can find about the classpath entry is a FAQ entry at http://maven.apache.org/plugins/maven-ejb-plugin/faq.html, but this rather cryptic explanation doesn't indicate why you might want to do this (although it seems clear from your explanation that it is necessary), or why this behaviour isn't the default behaviour for the plugin. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Garvin LeClaire [EMAIL PROTECTED]
Re: Maven Site Plugin
Wendy,
I'll work with you today if you have time and we'll try out the
struts site. The ${modules} reference will now be replaced with the
new references. I put back in support for all the legacy stuff I
noticed as it changed drastically from beta-5 to the present. The
configuration for the site descriptor and any configurations should
be considered part of the API. I've deployed a new snapshot. I will
also have to release doxia as the new version works in there now.
Jason.
On 15 Dec 06, at 1:43 AM 15 Dec 06, Jason van Zyl wrote:
On 14 Dec 06, at 11:29 PM 14 Dec 06, Wendy Smoak wrote:
On 12/14/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
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.
...
Thanks for doing this. But... (you knew it was coming) I'm having
trouble with it when site.xml contains ${modules}. I get this:
[INFO]
-
---
[ERROR] BUILD ERROR
[INFO]
-
---
[INFO] Error parsing site descriptor
Embedded error: expected START_TAG or END_TAG not TEXT (position:
TEXT seen ...a
ilreader, el-example, scripting-mailreader]\r\n\r\n
Those are the modules beneath struts-apps, here:
http://svn.apache.org/repos/asf/struts/struts1/trunk/apps/pom.xml
This is the site.xml:
http://svn.apache.org/repos/asf/struts/struts1/trunk/apps/src/
site/site.xml
Yup, that one's easy to fix. I'll do that tomorrow. Thanks for
testing that.
Jason.
--
Wendy
-
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: Maven Site Plugin
On 15 Dec 06, at 3:03 AM 15 Dec 06, Brett Porter wrote: I haven't looked, but this can't be right. Thte only things you need to match are: - doxia-sink-api - maven-reporting-api I started with the doxia version that was in 2.0.4 to make sure there were no problems. So I've whittled it down to 2 classes and some code from plexus-utils. This should allow people to do multi-page reports if they like and use the SinkFactory in doxia. Not much we can do about plexus-utils as it's in the core. These are quite small, but were impacted by Kenney's change which is where the incompat. came in. I have certainly used newer doxia site renderer/etc. code with maven 2.0.4. I'm not going to have time to look at this for a couple of days, but something is seriously wrong if this was necessary. Yah, it's just way to long for releases so it takes days to get up to speed. I was just overly cautious but it works now with all my tests. I've updated the copyright and will deploy everything for voting. This will also require a release of doxia. I'll do that as well. Jason. - Brett On 15/12/2006, at 8:55 AM, Jason van Zyl wrote: Hi, 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] - 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: [m2] Dev help needed: Should multiple repositories be able to host an artifact, potentially with different versions
Hi, I'm following this setup/process: - We have the following repository definitions in the root pom of the projects: * repository central - inherited, for normal non-snapshot artifacts * pluginRepository central - inherited, for normal non-snapshot plugins * repository company.repo for releases of normal artifacts * repository company.snapshot.repo for snapshots of normal artifacts * pluginRepository company.repo for releases of plugins (company local plugins) * pluginRepository company.snapshot.repo for snapshots of plugins (both company local and official maven/mojo plugins) - By default, there are only company local plugins present in the company.* repositories. No snapshot versions of maven/mojo plugins are used. - When I fix a bug in a maven plugin, and I don't deploy it to the people.apache snapshot repo, I mvn install it locally and then manually copy the plugin dir (with only my version) to the pluginRepository company.snapshot.repo. The filename contains -SNAPSHOT so you will overwrite previous versions. Maven should pick up on this but it might not. It's safer to do this: mvn deploy -DaltDeploymentRepository=company.snapshot.repo:default:scp://repo.company.com/path/ - colleagues will automatically get the snapshot version of the plugin, but due to a a bug in maven 2.0.4 they could end up with the wrong plugin in the reactor. For instance: mvn o.a.m.p:maven-assembly-plugin:2.3-SNAPSHOT:directory will first list the 2.3 version, and in the lifecycle fork maven will resolve to 2.2. To overcome this, I specify the version for the bugfixed-plugins in pluginManagement in the root pom. This way you're sure that your fixed version is used. If you require non-snapshot versions of plugins because you need to release, you can follow the process described at the wiki page you listed, to change the version to -INTERNAL. Another solution (not tested) is to specify the timestamped version instead of using the SNAPSHOT keyword - I'm hoping here that the release plugin will not complain then. So, basically: do NOT specify the maven plugin snapshot repo anywhere, but only an internal one, and manually manage what snapshot plugins are hosted there. It serves as an override of the non-snapshot central repo. This approach works quite well for me. -- Kenney Barrie Treloar wrote: See http://www.nabble.com/forum/ViewPost.jtp?post=7884079&framed=y&skin=177 for full discussion. The problem is that a plugin contains defects that have not yet been resolved in a release. The defect may be fixed in a snapshot version or there may be an unapplied patch available. The releases of your companies artifacts can't use snapshot versions and internally patched versions of the plugins needs to be made available to all developers. My original stab at providing process guidance around this is at http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins. Other people have attempted to follow this and have found shortcomings because the repository for all versions of an artifact is based on that last repository that had metadata for the artifact. e.g. internal_plugins and central both have metadata for plugin X, the repository is set to internal_plugins, which also contains the latest version, and then the repository reset to central. At this point the build process fails because central does not contain the specified version. I can't find any decent use cases for why you want an artifact to be available from multiple repositories. The two I can think of are 1) an artifact moves to another repository, e.g. codehaus to maven. In this case the artifiact id usuallu changes too from a form of -maven-plugin to maven--plugin. So this problem would never have been noticed before. 2) you are creating an internal patch repository. The current work around is to change the artifactId as part of the plugin patching process. I would like the opinion of some maven-devs on this and whether it makes sense to support this better in maven, or to continue with the workarounds available. Thanks. - 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]
Detecting current build definition
Hi, I'm not sure this is the correct forum, but the user-list didn't seem like a likely forum either. I'm creating a custom notifier, and need to detect which build definition that triggers it. I need to do this to enable different actions according to which definition the failure occurs in. I know how to retrieve the Project and the BuildDefinitions from it, but can't figure out how to find the current definition. Any idea? Thanks, Anders,
Re: Maven Site Plugin
I haven't looked, but this can't be right. Thte only things you need to match are: - doxia-sink-api - maven-reporting-api These are quite small, but were impacted by Kenney's change which is where the incompat. came in. I have certainly used newer doxia site renderer/etc. code with maven 2.0.4. I'm not going to have time to look at this for a couple of days, but something is seriously wrong if this was necessary. - Brett On 15/12/2006, at 8:55 AM, Jason van Zyl wrote: Hi, 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and Fedora
On 15/12/2006, at 1:51 AM, Jason van Zyl wrote: On 14 Dec 06, at 9:46 AM 14 Dec 06, Carl Trieloff wrote: Suggestion: Would a good starting point be to maybe be to create a branch where some guys can work, and then we work item by item with the maven community. once we get an issue out the way, and agreed by maven team we merge the branch and start the next item? If they are Apache committers then they already have access to our sandbox. If they aren't then we can do it somewhere like the mojo project where we can give you access. So, to elaborate, Carl - as an Apache committer you are entitled to svn cp maven trunk into the sandbox as maven-fedora-integration or something similar and drive this, if you like. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Site Plugin
On 14 Dec 06, at 11:29 PM 14 Dec 06, Wendy Smoak wrote:
On 12/14/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
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.
...
Thanks for doing this. But... (you knew it was coming) I'm having
trouble with it when site.xml contains ${modules}. I get this:
[INFO]
--
--
[ERROR] BUILD ERROR
[INFO]
--
--
[INFO] Error parsing site descriptor
Embedded error: expected START_TAG or END_TAG not TEXT (position:
TEXT seen ...a
ilreader, el-example, scripting-mailreader]\r\n\r\n
Those are the modules beneath struts-apps, here:
http://svn.apache.org/repos/asf/struts/struts1/trunk/apps/pom.xml
This is the site.xml:
http://svn.apache.org/repos/asf/struts/struts1/trunk/apps/src/site/
site.xml
Yup, that one's easy to fix. I'll do that tomorrow. Thanks for
testing that.
Jason.
--
Wendy
-
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: maven-ear-plugin and dependencies
On Thu, December 14, 2006 9:05 pm, Stephane Nicoll wrote: > This has been tackled a dozen of times and I am not sure it has > anything to do with the EAR plugin, at least if we follow the spec. If > I am wrong, please let me know. > > The valid way to bundle shared components/libs in a EAR is to define > the Class-Path entry of the manifest in EJB module(s) using the > component. It's certainly not by adding them in a module entry > in the application.xml even though some application servers support > this (JBoss namely). > > The EAR plugin supports the APP-INF/lib weblogic's trick by using the > defaultJarBundleDir setting though. > > So I wouldn't say the EAR plugin has no dependency management features > at all, I don't even see the point actually :) Make sure that your > classpath entries got generated on the EJB side and it will just run > fine. Ok, then I'll put it this way: it has no dependency management features that are clearly enough documented :) If you create an ejb using the default ejb configuration, and then you add this ejb to an ear file again with a default configuration, maven goes through all the motions and creates what looks like a valid ear file. But this ear file refuses to load into Jboss (the dreaded NoClassDefFound exception). Is there a reason why a spec compliant ejb and ear can't be created by default by the ejb and ear plugins? I'm asking from ignorance - I don't have in depth knowledge of the internal structure of an ear file, that being maven's job to worry about this stuff for me. The only mention I can find about the classpath entry is a FAQ entry at http://maven.apache.org/plugins/maven-ejb-plugin/faq.html, but this rather cryptic explanation doesn't indicate why you might want to do this (although it seems clear from your explanation that it is necessary), or why this behaviour isn't the default behaviour for the plugin. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
