Re: Generating md5 checksums
On Sat, 2004-01-17 at 19:57, Mark R. Diggory wrote: > Do there happen to be goals associated with this plugin, or do I need to > write my own. Seems there should be something basically identical to > > jar:deploy or dist:deploy goals that do the md5 checksum's as well? Use the repository:copy-artifact goal. You must override the setting for maven.repo.central. Just take a peek at the repository plugin and you can use all the tags in there you just have to make the apache repository your central repo and not ibiblio. > -Mark > > Mark R. Diggory wrote: > > Thanks, thats what I needed to know. > > > > [EMAIL PROTECTED] wrote: > > > >> Simply use the artifact tags : > >> http://maven.apache.org/reference/plugins/artifact/ > >> > >> -emmanuel > >> > >> Selon "Mark R. Diggory" <[EMAIL PROTECTED]>: > >> > >> > >>> Are there any details available on goals/properties necessary for > >>> generating md5 checksums for distributions and jars produced by maven? > >>> > >>> Thanks, > >>> -Mark > >>> -- > >>> Mark Diggory > >>> Software Developer > >>> Harvard MIT Data Center > >>> http://osprey.hmdc.harvard.edu > >>> > >>> - > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> > >> > >> > > -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
License link not generated for license.html
Hiya, Looks like in rc1 when the maven.license.licenseFile property is set to a file somewhere the license.html file is generated but the link to the license file is lost: no longer present within the project reports section of the maven generated site. Are there any workarounds? Thanks, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generating md5 checksums
Do there happen to be goals associated with this plugin, or do I need to write my own. Seems there should be something basically identical to jar:deploy or dist:deploy goals that do the md5 checksum's as well? -Mark Mark R. Diggory wrote: Thanks, thats what I needed to know. [EMAIL PROTECTED] wrote: Simply use the artifact tags : http://maven.apache.org/reference/plugins/artifact/ -emmanuel Selon "Mark R. Diggory" <[EMAIL PROTECTED]>: Are there any details available on goals/properties necessary for generating md5 checksums for distributions and jars produced by maven? Thanks, -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Subversion repository connection string example
Say does anyone have an example of a subversion configuration - I notice the docs on the project descriptor say subversion is supported but there are no examples for subversion. Thanks, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thoughts on project uniqness.
On Sat, 2004-01-17 at 13:16, Mark R. Diggory wrote: > But... > > With the possibility that multiple remote maven repositories can exist > and projects can be published that have the same project names to > different remote repositories, it seems there would really be issues > with name clashes eventually here? > > Seems that there should be some effort to make sure that projects > maintain uniqueness. Usually namespacing (using host domains) is used to > accomplish this (like in xml for instance). Is there any effort to do > this in maven repositories. > > Looking in the ibiblio repository, it seems there's going to eventually > be political issues with the whole apache commons, jakarta commons, xml > commons for instance if all jakarta commons projects have project names > "commons-*". > > This is where nested directory structures come into play. Which is > easier to maintain uniqueness? > > /jakarta.apache.org/commons/... > /xml.apache.org/commons/... > /commons.apache.org/... > > or > > /org > /apache >/jakarta > /commons >/xml > /commons >/commons > > or > > /commons-math/ > /commons-collections/ > /xml-apis > ... > > Seems theres some inherent uniqueness that could be enforced simply by > repository structure. Yup, look in the wiki. We've about various formats for the repository and it will be easy to support both new and old formats and we will switch at some point but probably not for 1.0 or 1.1. > -Mark -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSL applyTemplates Question
Troy Thibodeaux wrote: [Sorry, I accidentally sent an unfinished message before.] I'm having problems using jsl:applyTemplates in a stylesheet called in a Maven goal. When I use two applyTemplates tags in a row, and both tags contain select attributes using relative xpath, only the first tag is applied. It seems that the processor is losing the context for the second tag and the xpath is not being applied to the current node. When I use absolute xpath in the second applyTemplates, it fires as expected. Using applyTemplates without a select attribute applies all templates as expected as well. But in many cases I want to applyTemplates only to certain child nodes of the current node. I can use forEach instead, but for what I'm doing, that would require much redundant code. in site.jsl (xdoc plugin) we can read the code pasted below. i think this is a fix to the issue you're reporting, not ? [snip] -- gd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSL applyTemplates Question
[Sorry, I accidentally sent an unfinished message before.] I'm having problems using jsl:applyTemplates in a stylesheet called in a Maven goal. When I use two applyTemplates tags in a row, and both tags contain select attributes using relative xpath, only the first tag is applied. It seems that the processor is losing the context for the second tag and the xpath is not being applied to the current node. When I use absolute xpath in the second applyTemplates, it fires as expected. Using applyTemplates without a select attribute applies all templates as expected as well. But in many cases I want to applyTemplates only to certain child nodes of the current node. I can use forEach instead, but for what I'm doing, that would require much redundant code. Here is a simplified version of what I am attempting: the Maven goal contains: test.xml: This is one node This is another node test.jsl contains: Resulting test_out.xml: This is one node Thanks for any suggestions, Troy Thibodeaux - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thoughts on project uniqness.
Mark R. Diggory wrote: This is where nested directory structures come into play. Which is easier to maintain uniqueness? /jakarta.apache.org/commons/... /xml.apache.org/commons/... /commons.apache.org/... or /org /apache /jakarta /commons /xml /commons /commons or /commons-math/ /commons-collections/ /xml-apis ... This is the type of thing that the Apache Repository project was talking about. I think that they decided to use your 1st example, the fully qualified domain name of the "group". I also like this idea, I've been complaining about the current structure (with the 20 or so commons-* directories) for a while now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JSL applyTemplates Question
I'm having problems using jsl:applyTemplates in a stylesheet called in a Maven goal. Here is a simplified version of what I am attempting: the Maven goal test.xml: This is one node This is another node - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Thoughts on project uniqness.
But... With the possibility that multiple remote maven repositories can exist and projects can be published that have the same project names to different remote repositories, it seems there would really be issues with name clashes eventually here? Seems that there should be some effort to make sure that projects maintain uniqueness. Usually namespacing (using host domains) is used to accomplish this (like in xml for instance). Is there any effort to do this in maven repositories. Looking in the ibiblio repository, it seems there's going to eventually be political issues with the whole apache commons, jakarta commons, xml commons for instance if all jakarta commons projects have project names "commons-*". This is where nested directory structures come into play. Which is easier to maintain uniqueness? /jakarta.apache.org/commons/... /xml.apache.org/commons/... /commons.apache.org/... or /org /apache /jakarta /commons /xml /commons /commons or /commons-math/ /commons-collections/ /xml-apis ... Seems theres some inherent uniqueness that could be enforced simply by repository structure. -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Maven Developer Repostory
Yes, thats a little too "left field" isn't it. I'll stick to the game plan. -M. Jason van Zyl wrote: On Fri, 2004-01-16 at 20:00, Mark R. Diggory wrote: I was just looking over the "dist" directory and having wild thoughts: 1.) most of the projects are in nested directories ie: jakarta/commons/collections dist/**/ project/ source/ binary/ 2.) maven requires the remote repository to be in the following structure: repository/ project/ jars/ distribution/ Are there any thoughts on haw the dist directory itself might be maintained as a maven repository. For instance, is it plausible to have maven "projects" nested within the directory structure, or is this a limitation in Maven's Repository Structure? It's not something we want. If you want to let people use the existing structure then just write to move stuff from the dist structure to a maven repository structure. On a daily basic you could nuke the copied structure so the size wouldn't build to an unmanageable size. Then you can keep your dist structure and just flush new artifacts to ibiblio. repository/**/ project/ jars/ distribution/ Is it plausible that a project could actually organize where its "distribution" and "jars" directories were actually located? No. It's not that complicated. Just copy the artifacts into the required structure. or would it be more logical to have projects eventually migrate to the maven repository structure for deployment (until then, simlinking source and binary contents mainatained in the current process into maven/repository/project/distributions)? If you want to have it work with Maven then even a temporary structure would work for syncing. All you really want is to move new artifacts to the repository. There is no reason why the existing apache layout for the dist directories can't be maintained as well as shuffling them about to conform to what Maven needs so that a directory can be flushed to ibiblio. -Mark Jason van Zyl wrote: On Fri, 2004-01-16 at 11:03, Mark R. Diggory wrote: I'm not sure if this got onto the maven groups radar. I'd like to get feedback from the Maven group (or others who have access to ibiblio for deploying artifacts). What is your position on managing/maintain a maven ropository locally here on apache servers that will be used to supply the ibiblio mirror with all our "Apache Artifacts"? I say just get infrastructure to make a directory that is accessible to committers and then it only takes a minute to mail the ibiblio admins to pull from Apache at a 4 hour intervals. Are there any "local" Maven repositories in standard locations on servers like cvs.apache.org? Not yet, but you ask infrastructure what you would like and I'm sure they would be happy to service your request. If you get directory structure happening, I would be happy to contact to ibiblio and give them the details so they can setup the pull. This would definitely work right now, and if you want to do it in the dist directory so your repo gets mirrored then people can use those as well. They would just simply have to point at their local mirror containing the repository by adding an entry in their build.properties. Happy to help on the ibiblio end if you get things set up here, but there are no objections here. -- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Maven Developer Repostory
On Fri, 2004-01-16 at 20:00, Mark R. Diggory wrote: > I was just looking over the "dist" directory and having wild thoughts: > > 1.) most of the projects are in nested directories > > ie: jakarta/commons/collections > > dist/**/ > project/ > source/ > binary/ > > 2.) maven requires the remote repository to be in the following structure: > > repository/ > project/ >jars/ >distribution/ > > Are there any thoughts on haw the dist directory itself might be > maintained as a maven repository. For instance, is it plausible to have > maven "projects" nested within the directory structure, or is this a > limitation in Maven's Repository Structure? It's not something we want. If you want to let people use the existing structure then just write to move stuff from the dist structure to a maven repository structure. On a daily basic you could nuke the copied structure so the size wouldn't build to an unmanageable size. Then you can keep your dist structure and just flush new artifacts to ibiblio. > repository/**/ > project/ >jars/ >distribution/ > > Is it plausible that a project could actually organize where its > "distribution" and "jars" directories were actually located? No. It's not that complicated. Just copy the artifacts into the required structure. > or would it be more logical to have projects eventually migrate to the > maven repository structure for deployment (until then, simlinking source > and binary contents mainatained in the current process into > maven/repository/project/distributions)? If you want to have it work with Maven then even a temporary structure would work for syncing. All you really want is to move new artifacts to the repository. There is no reason why the existing apache layout for the dist directories can't be maintained as well as shuffling them about to conform to what Maven needs so that a directory can be flushed to ibiblio. > -Mark > > > > Jason van Zyl wrote: > > > On Fri, 2004-01-16 at 11:03, Mark R. Diggory wrote: > > > >>I'm not sure if this got onto the maven groups radar. > >> > >>I'd like to get feedback from the Maven group (or others who have access > >>to ibiblio for deploying artifacts). > >> > >>What is your position on managing/maintain a maven ropository locally > >>here on apache servers that will be used to supply the ibiblio mirror > >>with all our "Apache Artifacts"? > > > > > > I say just get infrastructure to make a directory that is accessible to > > committers and then it only takes a minute to mail the ibiblio admins to > > pull from Apache at a 4 hour intervals. > > > > > >>Are there any "local" Maven repositories in standard locations on > >>servers like cvs.apache.org? > > > > > > Not yet, but you ask infrastructure what you would like and I'm sure > > they would be happy to service your request. > > > > If you get directory structure happening, I would be happy to contact to > > ibiblio and give them the details so they can setup the pull. > > > > This would definitely work right now, and if you want to do it in the > > dist directory so your repo gets mirrored then people can use those as > > well. They would just simply have to point at their local mirror > > containing the repository by adding an entry in their build.properties. > > > > Happy to help on the ibiblio end if you get things set up here, but > > there are no objections here. > > -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
