Re: AW: creating a project
Matthias Dorfner schrieb: > Hi, > > I can now answer the question myself. If you want to create an skeleton with > site structure for a already existing project, you have to run e.g. the > archetype quickstart plugin first, second the e.g. > maven-archetype-site-simple plugin. Of course both with same group and > artifact Id. > > But the "out-of-the-box" linking for project information, project reports > html files which is generated automatically by running the mvn site command > is now on your own, as far as I know. > > Is there a "blank" index.apt somewhere which includes all these standard > links? > See http://maven.apache.org/guides/mini/guide-site.html. What you need to create a navigation of your site with the links mentioned is a site.xml file and not the index.apt. "" in the site.xml will create links for all your configured reports in poms reporting section. HTH Felix > Thank you! > > Regards, > Matthias > > -Ursprüngliche Nachricht- > Von: Matthias Dorfner [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 29. September 2008 15:56 > An: users@maven.apache.org > Betreff: creating a project > > Hi guys, > > > > I use this command from the archetype plugin: > > > > Mvn archetype:create -DarchetpeGroupId=org.apache.maven.archetypes \ > > -DarchetypeArtifactId=maven-archetype-site \ > > -DgroupId=com.mycompany \ > > -DartifactId=my-site > > > > It creates a dedicated site project where I can customize the layout and the > html (via apt, faq files etc.) output stuff. How can I integrate my java > sources and reports for that sources (e.g. from javadoc, checkstyle, pmd, > xref...) to this site? > > > > Regards, > > Matthias > > > > > > - > 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 schemaspy plugin with MSSql
Hi Wayne, Thanks for your reply. I've also tried that with jdbcUrl: jdbc:jtds:sqlserver://[host]:[port];DatabaseName=[DbName] But it still don't work. Regards, Arsen -- View this message in context: http://www.nabble.com/Maven-schemaspy-plugin-with-MSSql-tp19719190p19736586.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: YUICompressor plugin going ape
additionally I would try running the build with command line maven (is settable in project's properties) In fact the command line maven execution will be default in netbeans 6.5 as the embedded build is encountering many problems. Incompatibility with the latest released bits, bugs, not having plugins ready for embedded use. Milos On Thu, Sep 11, 2008 at 6:56 PM, nicolas de loof <[EMAIL PROTECTED]> wrote: > This plugin is not part of standard maven plugins. > Please report your issue to alchim.sf.net > > 2008/9/11 John Coleman <[EMAIL PROTECTED]> > >> Hi, >> >> The YUICompressor plugin gives the dump below. Anyone have any ideas why >> this should suddenly go wrong? We already tried to get a fresh update >> from the central repo. >> >> Is this maybe a mvn version issue given that it is a core mvn plugin >> class missing? >> >> TIA, >> John >> >> >> >> >> Using default encoding to copy filtered resources. >> >> [yuicompressor:compress] >> [FATAL]net.sf.alchim.mojo.yuicompressor.YuiCompressorMojo#execute() >> caused a linkage error (java.lang.NoClassDefFoundError). Check the >> realms: >> [FATAL]NOTE: >> [FATAL]Plugin realm is: >> /plugins/net.sf.alchim:yuicompressor-maven-plugin:[EMAIL >> PROTECTED]/thread:exec_B >> uild eTraderII_17 >> [FATAL]Container realm is: plexus.core >> [FATAL]Realm ID: >> /plugins/net.sf.alchim:yuicompressor-maven-plugin:[EMAIL >> PROTECTED]/thread:exec_B >> uild eTraderII_17 >> [FATAL]urls[0] = >> file:/C:/Documents%20and%20Settings/user/.m2/repository/net/sf/alchim/yu >> icompressor-maven-plugin/0.6.3/yuicompressor-maven-plugin-0.6.3.jar >> [FATAL]urls[1] = >> file:/C:/Documents%20and%20Settings/user/.m2/repository/rhino/js/1.6R7/j >> s-1.6R7.jar >> [FATAL]urls[2] = >> file:/C:/Documents%20and%20Settings/user/.m2/repository/net/sf/retrotran >> slator/retrotranslator-runtime/1.2.1/retrotranslator-runtime-1.2.1.jar >> [FATAL]urls[3] = >> file:/C:/Documents%20and%20Settings/user/.m2/repository/backport-util-co >> ncurrent/backport-util-concurrent/3.0/backport-util-concurrent-3.0.jar >> [FATAL]Realm ID: plexus.core >> [FATAL]urls[0] = >> file:/C:/Documents%20and%20Settings/user/.netbeans/6.1/maven2/rootpackag >> e/ >> java.lang.NoClassDefFoundError: >> org/codehaus/plexus/util/DirectoryScanner >>at >> net.sf.alchim.mojo.yuicompressor.MojoSupport.processDir(MojoSupport.java >> :133) >>at >> net.sf.alchim.mojo.yuicompressor.MojoSupport.execute(MojoSupport.java:10 >> 3) >>at >> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa >> nager.java:579) >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle >> Failures(DefaultLifecycleExecutor.java:498) >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentFo >> rProject(DefaultLifecycleExecutor.java:265) >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( >> DefaultLifecycleExecutor.java:191) >>at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec >> ycleExecutor.java:149) >>at >> org.codehaus.mevenide.netbeans.embedder.exec.MyLifecycleExecutor.execute >> (MyLifecycleExecutor.java:72) >>at >> org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223) >>at >> org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.ja >> va:304) >>at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1) >>at >> org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedde >> r.java:904) >>at >> org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(Maven >> Embedder.java:304) >>at >> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1) >>at >> org.codehaus.mevenide.netbeans.execute.MavenJavaExecutor.run(MavenJavaEx >> ecutor.java:215) >>at >> org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:151) >> >> Eurobase International Limited and its subsidiaries (Eurobase) are unable >> to exercise control over the content of information in E-Mails. Any views >> and opinions expressed may be personal to the sender and are not necessarily >> those of Eurobase. Eurobase will not enter into any contractual obligations >> in respect of any part of its business in any E-mail. >> >> Privileged / confidential information may be contained in this message and >> /or any attachments. This E-mail is intended for the use of the addressee(s) >> only and may contain confidential information. If you are not the / an >> intended recipient, you are hereby notified that any use or dissemination of >> this communication is strictly prohibited. If you receive this transmission >> in error, please notify us immediately, and then delete this E-mail. >> >> Neither the sender nor Eurobase accepts any liability whatsoever for any >> defects of any kind either in or arising from this E-mail transmission. >> E-Mail transmission cannot be guaranteed to be
Re: Maven schemaspy plugin with MSSql
Perhaps you should consider using the jdbcUrl parameter instead? That should let you pass the port info, I would assume. *Note: I've never used this plugin, just glanced at the docs. Wayne On Mon, Sep 29, 2008 at 9:45 PM, Sench <[EMAIL PROTECTED]> wrote: > > Hi Brad, > Thanks for your reply. > > I needn't to download source, I'll wait still normal version would be > released. > Thanks! > -- > View this message in context: > http://www.nabble.com/Maven-schemaspy-plugin-with-MSSql-tp19719190p19736091.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > 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 schemaspy plugin with MSSql
Hi Brad, Thanks for your reply. I needn't to download source, I'll wait still normal version would be released. Thanks! -- View this message in context: http://www.nabble.com/Maven-schemaspy-plugin-with-MSSql-tp19719190p19736091.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Site deployment to sourceforge.net broken
Is there an official answer for Marat's question? Can site plugin be configured to deploy file by file instead of zip/unzip? Thanks. http://sourceforge.net/community/forum/topic.php?id=3518&page&replies=1 Regards -Jiaqi Guo SourceForge Marat Radchenko wrote: After last changes in sf.net infrastructure there are three ways of uploading stuff to web area: 1) sftp 2) scp 3) rsync over ssh I've tried two first options and they both failed. Maven uploads zip file (wagon.zip) and then tries to unzip it. However unzip commandis not available. As far as I understand, Maven doesn't support site deployment via rsync. Am I doing something wrong or it is a real bug? Any existing workarounds? - 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: Are we blocked by central Maven repo?
On Tue, Sep 30, 2008 at 9:38 AM, Jason van Zyl <[EMAIL PROTECTED]> wrote: > We could start publishing a feed, but depending on the IP of the machine is > probably not the best idea. Given that we've installed a load balancer the > IP you get is going to be a whatever you get. > Thanks for the info. We'll have to address our setup and either find a mirror with a fixed IP or see if we can do this another way (second option is up to my IS dept, not me). Thanks, Ed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing project version number from Java
I use this little snippet inside ant build.xml target named
versionProperties to generate a Java file that gets compiled and provides a
constant (as ProgramVersion.VERSION):
package com.company.version;
/** Generated in ANT */
public class ProgramVersion
{
public static final String VERSION = "${program.version}";
}
Then this goes inside the section of the pom:
maven-antrun-plugin
generate-sources
run
${project.build.directory}/generated-sources/java
No need to use the pom.version value to set it but you do have to not put a
double-quote or a newline in there.
It works.
-- Lee
On Mon, Sep 29, 2008 at 7:37 AM, Dominic Mitchell <[EMAIL PROTECTED]> wrote:
> On 29 Sep 2008, at 13:22, Mark Hobson wrote:
>
> 2008/9/29 Dominic Mitchell <[EMAIL PROTECTED]>:
>>
>>> What's the easiest way to get at the version number in the POM from Java?
>>>
>>> I've been using
>>> getResourceAsStream('META-INF/maven/groupId/artifactId/pom.properties');
>>> But this doesn't work while I'm developing in Eclipse (only when using
>>> the
>>> built jar file).
>>>
>>
>> You can use maven-runtime to dynamically obtain this information, but
>> it still has the limitation of requiring the META-INF files created at
>> package-time:
>>
>> http://maven.apache.org/shared/maven-runtime/
>>
>>
> Aha! Thanks for pointing this out. That's much more useful than rolling
> my own implementation of such a thing.
>
> I'd quite like to see the generation of these metadata files occur at
>> the generate-resources phase of the lifecycle which would allow it
>> work within the IDE too.
>>
>
> -Dom
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
-- Lee Meador
Sent from gmail. My real email address is lee AT leemeador.com
Re: Are we blocked by central Maven repo?
We could start publishing a feed, but depending on the IP of the machine is probably not the best idea. Given that we've installed a load balancer the IP you get is going to be a whatever you get. On 29-Sep-08, at 6:59 PM, Ed Hillmann wrote: 2008/9/30 Dan Tran <[EMAIL PROTECTED]>: repo1.maven.org has a new IP Address, so if you hardcoded repo1.maven.org in your /etc/hosts you will have this problem. Sorry if this s a repeat. -D We're having this exact same problem. Our Nexus repository suddenly over the weekend couldn't access repo1. The machine on which the Nexus repository runs has limited access to the internet, based on IP address. So, if repo1's address has changed, this will be the cause. Thanks for the info! It wasn't a repeat for me, as I must have missed the first time. Given that we're pretty much dependant on that IP address not changing, I wish there was a better notification system for changes to central. It's just buggered up all of our builds for the last 1 1/2 days. Thanks, Ed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are we blocked by central Maven repo?
2008/9/30 Dan Tran <[EMAIL PROTECTED]>: > repo1.maven.org has a new IP Address, so if you hardcoded > repo1.maven.org in your /etc/hosts you will have this problem. Sorry > if this s a repeat. > > -D We're having this exact same problem. Our Nexus repository suddenly over the weekend couldn't access repo1. The machine on which the Nexus repository runs has limited access to the internet, based on IP address. So, if repo1's address has changed, this will be the cause. Thanks for the info! It wasn't a repeat for me, as I must have missed the first time. Given that we're pretty much dependant on that IP address not changing, I wish there was a better notification system for changes to central. It's just buggered up all of our builds for the last 1 1/2 days. Thanks, Ed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are we blocked by central Maven repo?
repo1.maven.org has a new IP Address, so if you hardcoded
repo1.maven.org in your /etc/hosts you will have this problem. Sorry
if this s a repeat.
-D
2008/9/26 Beyer,Nathan <[EMAIL PROTECTED]>:
> It's possible that from the central repo's perspective, all traffic from your
> company may seem like it's coming from one IP address because of NAT.
>
> Using an internal mirror can help alleviate things. The most non-invasive
> mirror would be to rsync the central repo periodically and then modify
> internal DNS to point 'repo1.maven.org' to an internal IP address. You can
> save a lot of bandwidth and time this way.
>
> -Nathan
>
> -Original Message-
> From: 陈思淼 [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 26, 2008 10:47 AM
> To: Maven Users List
> Subject: Re: Are we blocked by central Maven repo?
>
> we didn't do that kind of thing. we have a company-level artifactory
> repository.someone didn't follow the rule but most of us are good citizen,
> and follow the maven RULE,
> Is maven block strategy to block IP too strict?
> Can I do anything to Fix it Up?
>
>
>
> 2008/9/26 Wayne Fay <[EMAIL PROTECTED]>
>
>> It is possible to get blocked if you are acting as a bad citizen
>> (downloading the entire Central repo using wget, for example). Have
>> you (or someone else at your company) attempted to do this from your
>> IP address?
>>
>> If not, the repo is probably just busy, or you had some random
>> Internet connection failure. Try again. "Normal" Maven usage of the
>> repo will not get you blocked.
>>
>> Wayne
>>
>> On Fri, Sep 26, 2008 at 7:37 AM, 陈思淼 <[EMAIL PROTECTED]> wrote:
>> > This's log from artifactory.
>> >
>> > 2008-09-26 22:27:28,025 [WARN ] (RemoteRepoBase.java:259{10}) -
>> repo1:
>> > Error in getting information for 'org/apache/maven
>> > /maven-model/2.0.4/maven-model-2.0.4.pom.sha1'
>> > (org.apache.commons.httpclient.ConnectionPoolTimeoutException: Timeout
>> > waiting
>> > for connection).
>> >
>> > we company only have one outlet IP address ,someone may download Maven
>> from
>> > apache and didn't set the Mirror of central in the conf/setting.xml. so
>> they
>> > download the pom directly from central? Is that the reason why the
>> central
>> > repo block our IP address?
>> >
>>
>
> --
> CONFIDENTIALITY NOTICE This message and any included attachments are from
> Cerner Corporation and are intended only for the addressee. The information
> contained in this message is confidential and may constitute inside or
> non-public information under international, federal, or state securities
> laws. Unauthorized forwarding, printing, copying, distribution, or use of
> such information is strictly prohibited and may be unlawful. If you are not
> the addressee, please promptly delete this message and notify the sender of
> the delivery error by e-mail or you may call Cerner's corporate offices in
> Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: reactor plugin "Embedded error: Roots differ"
Dan Fabulich wrote: Jorg Heymans wrote: The root-pom/pom.xml contains a modules section that just references the project modules ../modules Yup, this is a known bug MREACTOR-1 http://jira.codehaus.org/browse/MREACTOR-1 It'll be pretty tough to fix it, I think. :-( Wait, no, actually, I'm wrong. MREACTOR-1 is perfectly real, but the "Different roots" error you're getting is surprising to me; I can't reproduce it even following your directions. Note that, in the system you showed me, you should be able to go to the "modules" directory and do "mvn reactor:make -Dmake.folders=A/api" and get it to work. If that doesn't work, please put together a reduced test case (zip up a simplified set of Maven projects) and file a bug. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ConversionException
Hi,
what could be causing this exception (in maven 2.0.9)?
[INFO] Trace com.thoughtworks.xstream.converters.ConversionException:
dependenciesInfo : dependenciesInfo
Debugging information
message : dependenciesInfo : dependenciesInfo
cause-exception :
com.thoughtworks.xstream.mapper.CannotResolveClassException
cause-message : dependenciesInfo : dependenciesInfo
class : org.apache.maven.plugin.war.util.WebappStructure
required-type : org.apache.maven.plugin.war.util.WebappStructure
path: /webapp-structure/dependenciesInfo
line number : 10
---
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:63)
at
com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:45)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:46)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:117)
at
com.thoughtworks.xstream.core.ReferenceByXPathMarshallingStrategy.unmarshal(ReferenceByXPathMarshallingStrategy.java:29)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:846)
Here's what the pom looks like:
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
notificationWebUI
war
service.notification
notificationProject
1.1.2-SNAPSHOT
../pom.xml
${pom.groupId}
notificationClient
1.1.2-SNAPSHOT
provided
thanks
Dmitry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: javadoc plugin fails during mvn release:perform ?
Hi Tobias, Some more details about your project would probably help. Do your missing symbols happen to be related to types created by source code generation? I had run into a similar problem with one of my builds a couple months ago, so let me share what I found. I had a multi-module project which used the XMLBeans Maven Plugin to generate some code from XML Schema files. I had the plugin defined in the module POM and had it configured to use JDK 1.5, which means amongst other things, that it creates get*List() methods in addition to get*Array() methods. The reactor project built fine, and I was able to successfully run site:site. After successfully running release:prepare, I tried release:perform, and all of a sudden the build failed with an error like: cannot find symbol symbol : method getPropertyList() location: interface I investigated this and found that the problem was that the XMLBeans Maven Plugin was being run multiple times during a reactor build, and during the site generation process it was being re-run but without the proper plugin configuration (specifically javaSource = 1.5 was not set). As a result, the get*List() versions of the methods were not being generated and the build failed. I tried several things to resolve this issue. I found that the only solution for me was to move the plugin configuration into the section of the root POM to insure that the configuration was always available, since for some unknown reason it was sometimes being omitted during a reactor build. This approach "resolved" the issue for me. I am not sure if this will help you at all, but I thought I would share in case you do have a similar configuration, or at least it may give you some ideas. I *think* this may be related to http://jira.codehaus.org/browse/MJAVADOC-179, but I am not sure. Good luck! ~Brad -Original Message- From: Tobias Gierke <[EMAIL PROTECTED]> Reply-To: Maven Users List To: Maven Users List Subject: javadoc plugin fails during mvn release:perform ? Date: Mon, 29 Sep 2008 18:13:45 +0200 Hi, How come the javadoc plugin fails with a 'cannot find symbol XYZ' error when running 'mvn release:perform' but 'mvn site' works fine ? Since compilation works I would assume my pom.xml contains all required dependencies. Maven version: 2.0.9 (i386 Linux) JDK version: 1.5 (tested with 1.6 as well, both fail) maven-release-plugin: 2.0-beta-7 javadoc-plugin: 2.4 My project uses a rather large parent POM , unfortunately I had no time to try to reproduce this issue with a simpler POM yet. (Plugin) version numbers are inherited from a parent POM, along with dependency version numbers (although these are not completely managed using , we're currently in a kind of 'transition phase' and use a mix of version properties and in our parent POM). Regards, Tobias - 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]
AW: creating a project
Hi, I can now answer the question myself. If you want to create an skeleton with site structure for a already existing project, you have to run e.g. the archetype quickstart plugin first, second the e.g. maven-archetype-site-simple plugin. Of course both with same group and artifact Id. But the "out-of-the-box" linking for project information, project reports html files which is generated automatically by running the mvn site command is now on your own, as far as I know. Is there a "blank" index.apt somewhere which includes all these standard links? Thank you! Regards, Matthias -Ursprüngliche Nachricht- Von: Matthias Dorfner [mailto:[EMAIL PROTECTED] Gesendet: Montag, 29. September 2008 15:56 An: users@maven.apache.org Betreff: creating a project Hi guys, I use this command from the archetype plugin: Mvn archetype:create -DarchetpeGroupId=org.apache.maven.archetypes \ -DarchetypeArtifactId=maven-archetype-site \ -DgroupId=com.mycompany \ -DartifactId=my-site It creates a dedicated site project where I can customize the layout and the html (via apt, faq files etc.) output stuff. How can I integrate my java sources and reports for that sources (e.g. from javadoc, checkstyle, pmd, xref...) to this site? Regards, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: reactor plugin "Embedded error: Roots differ"
Jorg Heymans wrote: The root-pom/pom.xml contains a modules section that just references the project modules ../modules Yup, this is a known bug MREACTOR-1 http://jira.codehaus.org/browse/MREACTOR-1 It'll be pretty tough to fix it, I think. :-( -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are we blocked by central Maven repo?
On 29-Sep-08, at 11:54 AM, Daniel Kulp wrote: On Monday 29 September 2008 10:59:48 am Jason van Zyl wrote: There is no rsync access to central. But the crawling is doing the equivalent amount of damage. I was suggesting creating a new public mirror that would be listable on http://maven.apache.org/guides/mini/guide-mirror-settings.html as a public mirror. Thus, it could be "pushed" from central like the other mirrors. From there, people could rsync from that repo instead of central or ibiblio or such. There is no upside to using rsync over a repository manager. I disagree. For one, with rsync, if the network goes down, and an artifact that a developer wants that hasn't yet been used is requested, nexus is useless. If your rsync just finished and the network hasn't gone down, and an artifact is released your developer makes a request for an artifact then your rsync'd repository is useless. There are potential holes in both cases but given the assumption your network is relatively healthy a repository manager is a more robust solution. Provided your CI mechanism is working against the repository manager it is going to be primed the vast majority of the time. The days of the repository being down for more then 10 minutes are over. So provided you have built in the recent past you have what you need. He's still stuck. With an rsync everything is available. This HAS bitten us. We have several developers that work from home offices and thus have their own repo manager setup or similar (or maybe don't use one). They develop stuff, commit some changes. The nightly builds then run but due to network hickups, fail as the artifacts couldn't be retrieved since those builds are the first to ask for them. Managers come running and screaming saying "maven sucks" cause the build fail. Anything that keeps the managers from running to me screaming maven sucks is a good thing. They don't care about repo managers, rsyncs, etc They just want their builds to not fail for stupid reasons. This is where repository managers vastly outstrip direct use. You can't do any routing to protect yourself, so bad metadata will hose your developers. I think your chances of problems with you developers are higher without a repository manager. Second, being a command line person, I like being able to login to the server and do something like "find . -name "*.pom" | xargs grep "somestring"" and such to find various things. (I know, the repo managers have search things, but gui's suck) You can do that with a repository manager that uses a file-based system like Nexus. The repository looks just like you expect unless you have your own store implementation. Nexus also has a rest API so you can have curl script to make a REST call to do a search, get a POM, an artifact, a configuration, the status. Anything that is available via the UI in Nexus is available via the CLI. The UI is just a REST client. Third, httpd can run and serve static files on some very lightweight hardware that cannot even begin to consider running java. As such, it's much faster than Nexus or others. Jetty using memory mapped buffers are really not that different. We are not currently doing that in Nexus but once we do it won't be that different. But the mediation that a repository manager provides means you can fix all sorts of crap you cannot drinking from the fire hose. Finally, this is the most important thing to me, each "mirrored" repository can be kept on a unique URL. http://proxy/central, http://proxy/java.net , http://proxy/apache-incubator, http://proxy/apache-snapshot, etc Thus, I can be sure that poms that are checked in have the appropriate entries that can resolve artifacts from their proper location in the absense of any repo manager.(Yes, Archiva can do this via the virtual repositories. Archiva is the only repo manager I would consider using because of this.) Nexus does this for certain, and I'm sure Artifactory does as well. But repositories in POMs are a bad practice and it's far easier to control everything from the repository manager. Repositories in POM make the artifacts non-portable which we've seen make a Maven environment pretty much unworkable. In an environment where you want partitioning and you promote artifacts based on quality (whether it's promoted to a different logical or physical repository) then you can have a build that is now targeted for a QA environment pointing back to a dev environment. Nexus can actually reroute any repository request in a POM but I consider it a Maven anti-pattern. The repository management side is now starting to parallel the changes that have happened in the build management side. I think it's a natural evolution in the use of Maven. That said, there are a lot of advantages to using a repo manager as we
javadoc plugin fails during mvn release:perform ?
Hi, How come the javadoc plugin fails with a 'cannot find symbol XYZ' error when running 'mvn release:perform' but 'mvn site' works fine ? Since compilation works I would assume my pom.xml contains all required dependencies. Maven version: 2.0.9 (i386 Linux) JDK version: 1.5 (tested with 1.6 as well, both fail) maven-release-plugin: 2.0-beta-7 javadoc-plugin: 2.4 My project uses a rather large parent POM , unfortunately I had no time to try to reproduce this issue with a simpler POM yet. (Plugin) version numbers are inherited from a parent POM, along with dependency version numbers (although these are not completely managed using , we're currently in a kind of 'transition phase' and use a mix of version properties and in our parent POM). Regards, Tobias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cannot run program "env"
Hi, after finishing my previous message I startet maven again, and got the error and maven stops again :confused: The behaviour is the same for root and my tomcat6 user account. I tried to give maven more memory, but did not help. (there are no min. mem. requirements for maven) Brett Porter wrote: > > Can you try running it under a different user account? > > - Brett > > 2008/9/29 greeklinux <[EMAIL PROTECTED]>: >> >> Hello, >> >> thanks for the reply. >> >> I tried a 2.0.9 version and the 2.1 preview releases, but the error still >> show up. >> "Error getting environment vars for profile activation >> java.io.IOException: >> Cannot run program "env": java.io.IOException: error=12, Cannot allocate >> memory" >> >> I read in other posts, that there was a bug with the environment >> variables. >> But mine are fine. >> >> The good thing is the error do not crash maven this time. >> The env command cannot run because maven cannot spawn other processes. I >> do >> not know >> how to modify this behaviour. >> >> >> >> >> >> >> Brett Porter wrote: >>> >>> I believe someone encountered this recently and it was a result of >>> running as the super user which had a very limited environment. You >>> might find more information in the archives. >>> >>> Cheers, >>> Brett >>> >>> 2008/9/29 greeklinux <[EMAIL PROTECTED]>: Hello, I am using maven, and I setup an CI system on a virtual server. When the build process starts, maven fails with the following error: Parsing POMs ERROR: Failed to parse POMs java.io.IOException: Cannot run program "env": java.io.IOException: error=12, Cannot allocate memory at java.lang.ProcessBuilder.start(ProcessBuilder.java:459) at java.lang.Runtime.exec(Runtime.java:593) at java.lang.Runtime.exec(Runtime.java:431) at java.lang.Runtime.exec(Runtime.java:328) at org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:250) at org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:216) at org.apache.maven.project.interpolation.RegexBasedModelInterpolator.(RegexBasedModelInterpolator.java:63) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:44) at org.codehaus.plexus.DefaultPlexusContainer.createComponentInstance(DefaultPlexusContainer.java:1464) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:93) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) at org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:129) at org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent(FieldComponentComposer.java:73) at org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:68) at org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexusContainer.java:1486) at org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:29) at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) at org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) at org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) at org.codehaus.plexus.embed.Embedder.lookup(Embedder.java:78) at hudson.maven.MavenEmbedder.start(MavenEmbedder.java:655) at hudson.maven.MavenUtil.createEmbedder(MavenUtil.java:75) at hudson.tasks.Maven
Re: Are we blocked by central Maven repo?
I'm not saying you are. It's the hundreds of other people trying it. You cannot sync against the central repository, you are syncing against ibiblio. Not the same thing. On 29-Sep-08, at 11:34 AM, Beyer,Nathan wrote: Rsync - http://maven.apache.org/guides/mini/guide-mirror- settings.html (see 'Creating your own mirror') We aren't crawling. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2008 10:00 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? There is no rsync access to central. But the crawling is doing the equivalent amount of damage. There is no upside to using rsync over a repository manager. On 29-Sep-08, at 10:51 AM, Daniel Kulp wrote: One thing I keep thinking about doing is creating a public mirror that is synced from central (it's a public mirror, thus, they would allow that), but provide rsync acess on some sort of paid agreement. Maybe $5/month or possibly just a ontime $100 setup fee or similar. Basically, enough to cover the bandwidth/hosting charges plus deter "everyone and their mother" from just rsyncing away.Is that something that people would have interest in? If I only had the time to get it setup... :-( Dan On Monday 29 September 2008 10:21:54 am Beyer,Nathan wrote: What would you suggest then? Anything that requires customized maven installs or modifying 'settings.xml' post install is not feasible in our environment - development is too distributed. In the long-run I believe the rsync approach does reduce bandwith, but more importantly, the concurrent access to the central repo via HTTP is close to nil. Additionally, as I mentioned, the repository managers are NOT stable and require too much configuration and setup. These are not acceptable options. The repository managers aren't providing any other value beyond central repo caching for us. If you're going to cut off anonymous rsync access, you might as well just kill anonymous central repo access too, as that's the only way you'll be able to force people into use repository managers. I would suggest more granular rsync access, so that requests can be more targeted. -Nathan -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 3:51 PM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? On 26-Sep-08, at 9:31 PM, Beyer,Nathan wrote: I disagree. 10gb or even 20gb isn't that much data, and rsync isn't pulling that same amount down every time it runs. We're doing it and it's working quite well. It's much more stable and reliable than any other current mirroring practices. The internal DNS modification makes user setup easy, since there isn't any. The use of mirror settings per device is a non-starter for large, disparate organizations. All of the various caching servers just aren't stable enough yet, in my opinion. It is possible to get blocked by the central repo - we were contacted about our significant usage and told we were on the verge of being blacklisted, which is what lead us to rsync the mirror. There is no way you could use less bandwidth rsyncing then using a repository manager. If everyone rsynced and we allowed that against central we would get destroyed. We only allow mirrors to rsync, not users and mirrors will probably also stop providing rsync access because the first hit is just too high now if everyone did it. -Nathan -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 11:11 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? IIRC Central is well over 10gb at this point (possibly 20gb) and a given organization will really only use at the most 1gb of it, so rsync'ing it is just a bad idea unless you are setting up an actual external mirror that will be available to the community. They are already using Artifactory, and I certainly hope/assume they are caching the results. This would limit their use of Central to one access per artifact (GAV) plus some hits by people not using their Artifactory instance. I would generally doubt they are actually blocked by Central, but rather this is an intermittent failure that will eventually resolve itself. Wayne 2008/9/26 Beyer,Nathan <[EMAIL PROTECTED]>: It's possible that from the central repo's perspective, all traffic from your company may seem like it's coming from one IP address because of NAT. Using an internal mirror can help alleviate things. The most non- invasive mirror would be to rsync the central repo periodically and then modify internal DNS to point 'repo1.maven.org' to an internal IP address. You can save a lot of bandwidth and time this way. -Nathan -Original Message- From: 陈思淼 [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 10:47 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? we didn't do that kind of thing. we have a company-le
[ANN] Maven Invoker Plugin 1.3 Released
The Maven team is pleased to announce the release of the Maven Invoker Plugin, version 1.3. http://maven.apache.org/plugins/maven-invoker-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-invoker-plugin 1.3 Release Notes - Maven 2.x Invoker Plugin - Version 1.3 ** Bug * [MINVOKER-47] - Test builds fail to locate staged artifacts when using custom settings and non-default local repo path * [MINVOKER-48] - Project cloning does not retain empty directories * [MINVOKER-51] - NPE when packaging is pom * [MINVOKER-53] - Filtering erroneously interpolates expressions from the POM even if prefix is neither project nor pom * [MINVOKER-59] - Using invoker.profiles with empty value causes unintended build * [MINVOKER-60] - Artifact staging misses attached artifact metadata of POM projects ** Improvement * [MINVOKER-55] - Filter IT POMs in-place if cloneProjectsTo is used * [MINVOKER-56] - Clone all projects which are locally reachable from the invoked IT project * [MINVOKER-62] - Change the default value for the projectsDirectory parameter * [MINVOKER-64] - invoker:install does not install dependencies unless they are in the reactor * [MINVOKER-65] - Support token "localRepositoryUrl" for filtering settings.xml * [MINVOKER-67] - Create interpolated settings file in cloneProjectsTo directory and keep it after execution ** New Feature * [MINVOKER-7] - Add groovy support for pre/post build hook scripts * [MINVOKER-36] - Support for non-project based Maven invocations * [MINVOKER-46] - Allow multiple invocations of Maven on the same project * [MINVOKER-49] - Inject global variable with path to local repo into hook scripts * [MINVOKER-50] - Filter all POMs that are relevant to the forked build * [MINVOKER-52] - Add a new mojo parameter to specify filter properties using the more convenient map-syntax * [MINVOKER-57] - Allow to configure M2_HOME and JAVA_HOME for the forked builds * [MINVOKER-58] - Allow to declare setup projects which must be run before all the rest * [MINVOKER-61] - Allow to ignore failures Enjoy, -The Maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven schemaspy plugin with MSSql
Hello, I am using Oracle and ran into this same issue when I tried to run the Maven SchemaSpy Plugin. I have looked at the source code briefly and it appears that it is not passing along some required arguments for certain databases (like the "-port" argument you have mentioned). There are also some other issues with the version of SchemaSpy that is embedded and modified within the plugin involving the classloader for loading the JDBC drivers for databases not directly supported by the plugin. I can only say for certain that the plugin currently works with Apache Derby without some modifications. I actually plan on trying to fix this soon because I think this is a great tool. When I do, I'll contact the plugin creator to see if I can contribute it. In the short term, your only option is to download the source code and try to patch it yourself. ~Brad -Original Message- From: Sench <[EMAIL PROTECTED]> Reply-To: Maven Users List To: users@maven.apache.org Subject: Maven schemaspy plugin with MSSql Date: Mon, 29 Sep 2008 00:10:02 -0700 (PDT) Hi all, Has anyone used before maven schemaspy plugin to generate DB schema site from MSSql? I'm trying to configure schemaspy plugin as described in http://maven.wakaleo.com/mojo/maven-schemaspy-plugin/usage.html http://maven.wakaleo.com/mojo/maven-schemaspy-plugin/usage.html as folows com.wakaleo.schemaspy maven-schemaspy-plugin 1.0 mssql [DbName] [Host] [Login] [Password] . But during build of my site I'm getting this error Parameter '-port' (database port on host) missing. It is required for the specified database type. Why maven schemaspy plugin didn't trying to connect to MSSql with defaul port? Or how can I pass port to maven schemaspy plugin? Plz help, Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JAR resources and WAR creation
I am interested in creating components that are made of Java classes packaged along with CSS and Javascript files. Components have dependencies between themselves. In the end, components are used to create web applications. I am thinking Maven is perfect for this, but I can not settle on the file format to use. Basically, in a Maven directory structure, a component is made of src/main/java files and webapp files. Yet, the preferred artifact file format would be JAR since other components requires the class files from it in their classpath. Finally, when all components are created, an all encompassing WAR application is built. When this happens, all the webapp files should be taken out of the JARs and put in the right places for WAR generation. In details, here would be the process. For a component: /src/main/java/**/*.java /src/main/webapp/**/* gets turned into a JAR: **/*.class META-INF/manifest.mf __webapp/**/* In final assembly into a WAR, all the files from the JARs under a __webapp directory gets copied into the top directory of the WAR. Is there anyone out there already performing similar packaging? If not, any suggestion on how to go about this would be appreciated. Thanks, JP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Are we blocked by central Maven repo?
As I mentioned in an earlier email, we rsync periodically, and override our internal DNS to redirect 'repo1.maven.org'. All internal developers automatically use the local copy. We don't crawl the repository. You may know people using Nexus for over a year that can't live without it. We've been using Apache web server mod_dav for three+ years with LDAP-based authentication and authorization - it has worked perfectly. As for all of your points about not having control of developers - a repository manager won't give me that either. There is no amount technology that can be applied to completely prevent any of those issues or countless others. I prefer to allow open access, facilitate developers, educate them and then review multiple times. The review points are where we begin to lock down and restrict access and the builds go through quality assurance, which can be automated. Locking down, filtering or controlling access up front prematurely limits innovation. I prefer to allow people to access what they want, as they want and as they move to later points in the process, then we tighten control as their builds move closer to manufacturing and work through dependency approval, license compliance, etc. -Nathan -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2008 9:59 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? On 29-Sep-08, at 10:21 AM, Beyer,Nathan wrote: > What would you suggest then? Anything that requires customized maven > installs or modifying 'settings.xml' post install is not feasible in > our environment - development is too distributed. So how do you used your rsync'd repository? How do you get all your developers to use your in-house repository which is a copy of central? Using repository managers makes distributed development an order of magnitude easier. > > > In the long-run I believe the rsync approach does reduce bandwith, > but more importantly, the concurrent access to the central repo via > HTTP is close to nil. Believe, as the one who looks at the logs and watch people crawl the repository this is not the case. In the long run you will see that you use less then 3% of what's in central so there is no point in pulling the bulk of the content. > > > Additionally, as I mentioned, the repository managers are NOT stable > and require too much configuration and setup. Hardly. We have people who have been using Nexus for over a year and they couldn't live without it now > These are not acceptable options. The repository managers aren't > providing any other value beyond central repo caching for us. > You have no idea what you're talking about. Sorry but you're are sadly mistaken. - Does your organization like your developers' builds crawling around every repository listed in a POM? You have no control over that without a repository manager. Tell your management that you're not controlling access to external repositories and see how much they like that. - You can create and manage access by all your developers from one location, if you have multiple repositories which most organizations have, this is a nightmare without a repository manager - IDE integration? Using a Nexus index you get complete autocompletion in the POM editor, ability to search for all plugins available, all archetypes available. - Routing around bad metadata protecting your developers from mis- formed POMs which can happen - Optimized searching for dependencies i.e. don't think around the world for your company's artifacts or only take Apache artifacts from the Apache repository - Repository federation, by proxing other repositories in Nexus you can search them all - Deployment with a simple PUT, no requirement for the WebDAV provider - Fine grained access to repositories i.e. far more powerful then access via Apache > If you're going to cut off anonymous rsync access, you might as well > just kill anonymous central repo access too, as that's the only way > you'll be able to force people into use repository managers. There is no anonymous rsync access to central, there never has been because the bandwidth charges would have made the situation unmanageable. We aren't forcing anyone to use repository managers, it boils down to a matter of cost in bandwidth. And people are using repository managers because it's just the smarter way to work with Maven. > > > I would suggest more granular rsync access, so that requests can be > more targeted. That pretty much amounts to the way a repository manager works. You're not going to get more targeted access then that. You get what you need and that's it. Run your CI system working against a repository manager will always keep your repository primed for use by your developers. > > > -Nathan > > -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: Friday, September 26, 20
Re: Are we blocked by central Maven repo?
On Monday 29 September 2008 10:59:48 am Jason van Zyl wrote: > There is no rsync access to central. But the crawling is doing the > equivalent amount of damage. I was suggesting creating a new public mirror that would be listable on http://maven.apache.org/guides/mini/guide-mirror-settings.html as a public mirror. Thus, it could be "pushed" from central like the other mirrors. From there, people could rsync from that repo instead of central or ibiblio or such. > There is no upside to using rsync over a repository manager. I disagree. For one, with rsync, if the network goes down, and an artifact that a developer wants that hasn't yet been used is requested, nexus is useless. He's still stuck. With an rsync everything is available. This HAS bitten us. We have several developers that work from home offices and thus have their own repo manager setup or similar (or maybe don't use one). They develop stuff, commit some changes. The nightly builds then run but due to network hickups, fail as the artifacts couldn't be retrieved since those builds are the first to ask for them. Managers come running and screaming saying "maven sucks" cause the build fail. Anything that keeps the managers from running to me screaming maven sucks is a good thing. They don't care about repo managers, rsyncs, etc They just want their builds to not fail for stupid reasons. Second, being a command line person, I like being able to login to the server and do something like "find . -name "*.pom" | xargs grep "somestring"" and such to find various things. (I know, the repo managers have search things, but gui's suck) Third, httpd can run and serve static files on some very lightweight hardware that cannot even begin to consider running java. As such, it's much faster than Nexus or others. Finally, this is the most important thing to me, each "mirrored" repository can be kept on a unique URL. http://proxy/central, http://proxy/java.net, http://proxy/apache-incubator, http://proxy/apache-snapshot, etc Thus, I can be sure that poms that are checked in have the appropriate entries that can resolve artifacts from their proper location in the absense of any repo manager.(Yes, Archiva can do this via the virtual repositories. Archiva is the only repo manager I would consider using because of this.) That said, there are a lot of advantages to using a repo manager as well. I admit that. But using a repo manager currently does not meet ALL requirements. Dan > > On 29-Sep-08, at 10:51 AM, Daniel Kulp wrote: > > One thing I keep thinking about doing is creating a public mirror > > that is > > synced from central (it's a public mirror, thus, they would allow > > that), but > > provide rsync acess on some sort of paid agreement. Maybe $5/month > > or > > possibly just a ontime $100 setup fee or similar. Basically, > > enough to > > cover the bandwidth/hosting charges plus deter "everyone and their > > mother" > > from just rsyncing away.Is that something that people would have > > interest > > in? > > > > If I only had the time to get it setup... :-( > > > > Dan > > -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Are we blocked by central Maven repo?
Rsync - http://maven.apache.org/guides/mini/guide-mirror-settings.html (see 'Creating your own mirror') We aren't crawling. -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2008 10:00 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? There is no rsync access to central. But the crawling is doing the equivalent amount of damage. There is no upside to using rsync over a repository manager. On 29-Sep-08, at 10:51 AM, Daniel Kulp wrote: > > One thing I keep thinking about doing is creating a public mirror > that is > synced from central (it's a public mirror, thus, they would allow > that), but > provide rsync acess on some sort of paid agreement. Maybe $5/month > or > possibly just a ontime $100 setup fee or similar. Basically, > enough to > cover the bandwidth/hosting charges plus deter "everyone and their > mother" > from just rsyncing away.Is that something that people would have > interest > in? > > If I only had the time to get it setup... :-( > > Dan > > > > On Monday 29 September 2008 10:21:54 am Beyer,Nathan wrote: >> What would you suggest then? Anything that requires customized maven >> installs or modifying 'settings.xml' post install is not feasible >> in our >> environment - development is too distributed. >> >> In the long-run I believe the rsync approach does reduce bandwith, >> but more >> importantly, the concurrent access to the central repo via HTTP is >> close to >> nil. >> >> Additionally, as I mentioned, the repository managers are NOT >> stable and >> require too much configuration and setup. These are not acceptable >> options. >> The repository managers aren't providing any other value beyond >> central >> repo caching for us. >> >> If you're going to cut off anonymous rsync access, you might as >> well just >> kill anonymous central repo access too, as that's the only way >> you'll be >> able to force people into use repository managers. >> >> I would suggest more granular rsync access, so that requests can be >> more >> targeted. >> >> -Nathan >> >> -Original Message- >> From: Jason van Zyl [mailto:[EMAIL PROTECTED] >> Sent: Friday, September 26, 2008 3:51 PM >> To: Maven Users List >> Subject: Re: Are we blocked by central Maven repo? >> >> On 26-Sep-08, at 9:31 PM, Beyer,Nathan wrote: >>> I disagree. 10gb or even 20gb isn't that much data, and rsync isn't >>> pulling that same amount down every time it runs. We're doing it and >>> it's working quite well. It's much more stable and reliable than any >>> other current mirroring practices. The internal DNS modification >>> makes user setup easy, since there isn't any. The use of mirror >>> settings per device is a non-starter for large, disparate >>> organizations. All of the various caching servers just aren't stable >>> enough yet, in my opinion. >>> >>> It is possible to get blocked by the central repo - we were >>> contacted about our significant usage and told we were on the verge >>> of being blacklisted, which is what lead us to rsync the mirror. >> >> There is no way you could use less bandwidth rsyncing then using a >> repository manager. If everyone rsynced and we allowed that against >> central we would get destroyed. We only allow mirrors to rsync, not >> users and mirrors will probably also stop providing rsync access >> because the first hit is just too high now if everyone did it. >> >>> -Nathan >>> >>> -Original Message- >>> From: Wayne Fay [mailto:[EMAIL PROTECTED] >>> Sent: Friday, September 26, 2008 11:11 AM >>> To: Maven Users List >>> Subject: Re: Are we blocked by central Maven repo? >>> >>> IIRC Central is well over 10gb at this point (possibly 20gb) and a >>> given organization will really only use at the most 1gb of it, so >>> rsync'ing it is just a bad idea unless you are setting up an actual >>> external mirror that will be available to the community. >>> >>> They are already using Artifactory, and I certainly hope/assume they >>> are caching the results. This would limit their use of Central to >>> one >>> access per artifact (GAV) plus some hits by people not using their >>> Artifactory instance. >>> >>> I would generally doubt they are actually blocked by Central, but >>> rather this is an intermittent failure that will eventually resolve >>> itself. >>> >>> Wayne >>> >>> 2008/9/26 Beyer,Nathan <[EMAIL PROTECTED]>: It's possible that from the central repo's perspective, all traffic from your company may seem like it's coming from one IP address because of NAT. Using an internal mirror can help alleviate things. The most non- invasive mirror would be to rsync the central repo periodically and then modify internal DNS to point 'repo1.maven.org' to an internal IP address. You can save a lot of bandwidth and time this way. -Nathan -Original Message- From: 陈思淼 [mailto:[EMAIL PROTECTED] Sent:
RE: Are we blocked by central Maven repo?
Does anyone have anecdotal proof that Nexus can handle significant loads? In my experience, it hasn't been able to scale beyond a small group of users (less than 25). I'm aware of this option, but none of the repository managers, in my experience, have been able to scale as well as a Apache web server loading artifacts from a filesystem. -Original Message- From: Stephen Connolly [mailto:[EMAIL PROTECTED] Sent: Monday, September 29, 2008 10:05 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? Here is a quick set up for you. On your local machine that you were using for the internal mirror: 1. Install Apache httpd 2.2 with mod_proxy_ajp 2. Install Nexus 3. Front Nexus through ajp on the Apache httpd 4. Use a rewrite rule for /maven2 to /nexus/content/repositories/central/ 5. Change your internal dns records so that repo1.maven.org points to this local machine Now you have the same mirroring capabilities as before, only lower bandwidth and everything will be hunky-dorey 6. If you want to be ultra-fancy, add mod-proxy rules to map anything that's not on the server through to the real repo1.maven.org -Stephen 2008/9/29 Beyer,Nathan <[EMAIL PROTECTED]> > What would you suggest then? Anything that requires customized maven > installs or modifying 'settings.xml' post install is not feasible in our > environment - development is too distributed. > > In the long-run I believe the rsync approach does reduce bandwith, but more > importantly, the concurrent access to the central repo via HTTP is close to > nil. > > Additionally, as I mentioned, the repository managers are NOT stable and > require too much configuration and setup. These are not acceptable options. > The repository managers aren't providing any other value beyond central repo > caching for us. > > If you're going to cut off anonymous rsync access, you might as well just > kill anonymous central repo access too, as that's the only way you'll be > able to force people into use repository managers. > > I would suggest more granular rsync access, so that requests can be more > targeted. > > -Nathan > > -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: Friday, September 26, 2008 3:51 PM > To: Maven Users List > Subject: Re: Are we blocked by central Maven repo? > > > On 26-Sep-08, at 9:31 PM, Beyer,Nathan wrote: > > > I disagree. 10gb or even 20gb isn't that much data, and rsync isn't > > pulling that same amount down every time it runs. We're doing it and > > it's working quite well. It's much more stable and reliable than any > > other current mirroring practices. The internal DNS modification > > makes user setup easy, since there isn't any. The use of mirror > > settings per device is a non-starter for large, disparate > > organizations. All of the various caching servers just aren't stable > > enough yet, in my opinion. > > > > It is possible to get blocked by the central repo - we were > > contacted about our significant usage and told we were on the verge > > of being blacklisted, which is what lead us to rsync the mirror. > > > > There is no way you could use less bandwidth rsyncing then using a > repository manager. If everyone rsynced and we allowed that against > central we would get destroyed. We only allow mirrors to rsync, not > users and mirrors will probably also stop providing rsync access > because the first hit is just too high now if everyone did it. > > > -Nathan > > > > -Original Message- > > From: Wayne Fay [mailto:[EMAIL PROTECTED] > > Sent: Friday, September 26, 2008 11:11 AM > > To: Maven Users List > > Subject: Re: Are we blocked by central Maven repo? > > > > IIRC Central is well over 10gb at this point (possibly 20gb) and a > > given organization will really only use at the most 1gb of it, so > > rsync'ing it is just a bad idea unless you are setting up an actual > > external mirror that will be available to the community. > > > > They are already using Artifactory, and I certainly hope/assume they > > are caching the results. This would limit their use of Central to one > > access per artifact (GAV) plus some hits by people not using their > > Artifactory instance. > > > > I would generally doubt they are actually blocked by Central, but > > rather this is an intermittent failure that will eventually resolve > > itself. > > > > Wayne > > > > 2008/9/26 Beyer,Nathan <[EMAIL PROTECTED]>: > >> It's possible that from the central repo's perspective, all traffic > >> from your company may seem like it's coming from one IP address > >> because of NAT. > >> > >> Using an internal mirror can help alleviate things. The most non- > >> invasive mirror would be to rsync the central repo periodically and > >> then modify internal DNS to point 'repo1.maven.org' to an internal > >> IP address. You can save a lot of bandwidth and time this way. > >> > >> -Nathan > >> > >> -Original Message- > >> From: 陈思淼 [mailto:[EMAIL PROTECTED] > >> Sent: Friday, S
Re: Are we blocked by central Maven repo?
There is no rsync access to central. But the crawling is doing the equivalent amount of damage. There is no upside to using rsync over a repository manager. On 29-Sep-08, at 10:51 AM, Daniel Kulp wrote: One thing I keep thinking about doing is creating a public mirror that is synced from central (it's a public mirror, thus, they would allow that), but provide rsync acess on some sort of paid agreement. Maybe $5/month or possibly just a ontime $100 setup fee or similar. Basically, enough to cover the bandwidth/hosting charges plus deter "everyone and their mother" from just rsyncing away.Is that something that people would have interest in? If I only had the time to get it setup... :-( Dan On Monday 29 September 2008 10:21:54 am Beyer,Nathan wrote: What would you suggest then? Anything that requires customized maven installs or modifying 'settings.xml' post install is not feasible in our environment - development is too distributed. In the long-run I believe the rsync approach does reduce bandwith, but more importantly, the concurrent access to the central repo via HTTP is close to nil. Additionally, as I mentioned, the repository managers are NOT stable and require too much configuration and setup. These are not acceptable options. The repository managers aren't providing any other value beyond central repo caching for us. If you're going to cut off anonymous rsync access, you might as well just kill anonymous central repo access too, as that's the only way you'll be able to force people into use repository managers. I would suggest more granular rsync access, so that requests can be more targeted. -Nathan -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 3:51 PM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? On 26-Sep-08, at 9:31 PM, Beyer,Nathan wrote: I disagree. 10gb or even 20gb isn't that much data, and rsync isn't pulling that same amount down every time it runs. We're doing it and it's working quite well. It's much more stable and reliable than any other current mirroring practices. The internal DNS modification makes user setup easy, since there isn't any. The use of mirror settings per device is a non-starter for large, disparate organizations. All of the various caching servers just aren't stable enough yet, in my opinion. It is possible to get blocked by the central repo - we were contacted about our significant usage and told we were on the verge of being blacklisted, which is what lead us to rsync the mirror. There is no way you could use less bandwidth rsyncing then using a repository manager. If everyone rsynced and we allowed that against central we would get destroyed. We only allow mirrors to rsync, not users and mirrors will probably also stop providing rsync access because the first hit is just too high now if everyone did it. -Nathan -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 11:11 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? IIRC Central is well over 10gb at this point (possibly 20gb) and a given organization will really only use at the most 1gb of it, so rsync'ing it is just a bad idea unless you are setting up an actual external mirror that will be available to the community. They are already using Artifactory, and I certainly hope/assume they are caching the results. This would limit their use of Central to one access per artifact (GAV) plus some hits by people not using their Artifactory instance. I would generally doubt they are actually blocked by Central, but rather this is an intermittent failure that will eventually resolve itself. Wayne 2008/9/26 Beyer,Nathan <[EMAIL PROTECTED]>: It's possible that from the central repo's perspective, all traffic from your company may seem like it's coming from one IP address because of NAT. Using an internal mirror can help alleviate things. The most non- invasive mirror would be to rsync the central repo periodically and then modify internal DNS to point 'repo1.maven.org' to an internal IP address. You can save a lot of bandwidth and time this way. -Nathan -Original Message- From: 陈思淼 [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 10:47 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? we didn't do that kind of thing. we have a company-level artifactory repository.someone didn't follow the rule but most of us are good citizen, and follow the maven RULE, Is maven block strategy to block IP too strict? Can I do anything to Fix it Up? 2008/9/26 Wayne Fay <[EMAIL PROTECTED]> It is possible to get blocked if you are acting as a bad citizen (downloading the entire Central repo using wget, for example). Have you (or someone else at your company) attempted to do this from your IP address? If not, the repo is probably just busy, or you
Re: Are we blocked by central Maven repo?
On 29-Sep-08, at 10:21 AM, Beyer,Nathan wrote: What would you suggest then? Anything that requires customized maven installs or modifying 'settings.xml' post install is not feasible in our environment - development is too distributed. So how do you used your rsync'd repository? How do you get all your developers to use your in-house repository which is a copy of central? Using repository managers makes distributed development an order of magnitude easier. In the long-run I believe the rsync approach does reduce bandwith, but more importantly, the concurrent access to the central repo via HTTP is close to nil. Believe, as the one who looks at the logs and watch people crawl the repository this is not the case. In the long run you will see that you use less then 3% of what's in central so there is no point in pulling the bulk of the content. Additionally, as I mentioned, the repository managers are NOT stable and require too much configuration and setup. Hardly. We have people who have been using Nexus for over a year and they couldn't live without it now These are not acceptable options. The repository managers aren't providing any other value beyond central repo caching for us. You have no idea what you're talking about. Sorry but you're are sadly mistaken. - Does your organization like your developers' builds crawling around every repository listed in a POM? You have no control over that without a repository manager. Tell your management that you're not controlling access to external repositories and see how much they like that. - You can create and manage access by all your developers from one location, if you have multiple repositories which most organizations have, this is a nightmare without a repository manager - IDE integration? Using a Nexus index you get complete autocompletion in the POM editor, ability to search for all plugins available, all archetypes available. - Routing around bad metadata protecting your developers from mis- formed POMs which can happen - Optimized searching for dependencies i.e. don't think around the world for your company's artifacts or only take Apache artifacts from the Apache repository - Repository federation, by proxing other repositories in Nexus you can search them all - Deployment with a simple PUT, no requirement for the WebDAV provider - Fine grained access to repositories i.e. far more powerful then access via Apache If you're going to cut off anonymous rsync access, you might as well just kill anonymous central repo access too, as that's the only way you'll be able to force people into use repository managers. There is no anonymous rsync access to central, there never has been because the bandwidth charges would have made the situation unmanageable. We aren't forcing anyone to use repository managers, it boils down to a matter of cost in bandwidth. And people are using repository managers because it's just the smarter way to work with Maven. I would suggest more granular rsync access, so that requests can be more targeted. That pretty much amounts to the way a repository manager works. You're not going to get more targeted access then that. You get what you need and that's it. Run your CI system working against a repository manager will always keep your repository primed for use by your developers. -Nathan -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 3:51 PM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? On 26-Sep-08, at 9:31 PM, Beyer,Nathan wrote: I disagree. 10gb or even 20gb isn't that much data, and rsync isn't pulling that same amount down every time it runs. We're doing it and it's working quite well. It's much more stable and reliable than any other current mirroring practices. The internal DNS modification makes user setup easy, since there isn't any. The use of mirror settings per device is a non-starter for large, disparate organizations. All of the various caching servers just aren't stable enough yet, in my opinion. It is possible to get blocked by the central repo - we were contacted about our significant usage and told we were on the verge of being blacklisted, which is what lead us to rsync the mirror. There is no way you could use less bandwidth rsyncing then using a repository manager. If everyone rsynced and we allowed that against central we would get destroyed. We only allow mirrors to rsync, not users and mirrors will probably also stop providing rsync access because the first hit is just too high now if everyone did it. -Nathan -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: Friday, September 26, 2008 11:11 AM To: Maven Users List Subject: Re: Are we blocked by central Maven repo? IIRC Central is well over 10gb at this point (possibly 20gb) and a given organization will really only use at the mo
Re: Are we blocked by central Maven repo?
Here is a quick set up for you. On your local machine that you were using for the internal mirror: 1. Install Apache httpd 2.2 with mod_proxy_ajp 2. Install Nexus 3. Front Nexus through ajp on the Apache httpd 4. Use a rewrite rule for /maven2 to /nexus/content/repositories/central/ 5. Change your internal dns records so that repo1.maven.org points to this local machine Now you have the same mirroring capabilities as before, only lower bandwidth and everything will be hunky-dorey 6. If you want to be ultra-fancy, add mod-proxy rules to map anything that's not on the server through to the real repo1.maven.org -Stephen 2008/9/29 Beyer,Nathan <[EMAIL PROTECTED]> > What would you suggest then? Anything that requires customized maven > installs or modifying 'settings.xml' post install is not feasible in our > environment - development is too distributed. > > In the long-run I believe the rsync approach does reduce bandwith, but more > importantly, the concurrent access to the central repo via HTTP is close to > nil. > > Additionally, as I mentioned, the repository managers are NOT stable and > require too much configuration and setup. These are not acceptable options. > The repository managers aren't providing any other value beyond central repo > caching for us. > > If you're going to cut off anonymous rsync access, you might as well just > kill anonymous central repo access too, as that's the only way you'll be > able to force people into use repository managers. > > I would suggest more granular rsync access, so that requests can be more > targeted. > > -Nathan > > -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: Friday, September 26, 2008 3:51 PM > To: Maven Users List > Subject: Re: Are we blocked by central Maven repo? > > > On 26-Sep-08, at 9:31 PM, Beyer,Nathan wrote: > > > I disagree. 10gb or even 20gb isn't that much data, and rsync isn't > > pulling that same amount down every time it runs. We're doing it and > > it's working quite well. It's much more stable and reliable than any > > other current mirroring practices. The internal DNS modification > > makes user setup easy, since there isn't any. The use of mirror > > settings per device is a non-starter for large, disparate > > organizations. All of the various caching servers just aren't stable > > enough yet, in my opinion. > > > > It is possible to get blocked by the central repo - we were > > contacted about our significant usage and told we were on the verge > > of being blacklisted, which is what lead us to rsync the mirror. > > > > There is no way you could use less bandwidth rsyncing then using a > repository manager. If everyone rsynced and we allowed that against > central we would get destroyed. We only allow mirrors to rsync, not > users and mirrors will probably also stop providing rsync access > because the first hit is just too high now if everyone did it. > > > -Nathan > > > > -Original Message- > > From: Wayne Fay [mailto:[EMAIL PROTECTED] > > Sent: Friday, September 26, 2008 11:11 AM > > To: Maven Users List > > Subject: Re: Are we blocked by central Maven repo? > > > > IIRC Central is well over 10gb at this point (possibly 20gb) and a > > given organization will really only use at the most 1gb of it, so > > rsync'ing it is just a bad idea unless you are setting up an actual > > external mirror that will be available to the community. > > > > They are already using Artifactory, and I certainly hope/assume they > > are caching the results. This would limit their use of Central to one > > access per artifact (GAV) plus some hits by people not using their > > Artifactory instance. > > > > I would generally doubt they are actually blocked by Central, but > > rather this is an intermittent failure that will eventually resolve > > itself. > > > > Wayne > > > > 2008/9/26 Beyer,Nathan <[EMAIL PROTECTED]>: > >> It's possible that from the central repo's perspective, all traffic > >> from your company may seem like it's coming from one IP address > >> because of NAT. > >> > >> Using an internal mirror can help alleviate things. The most non- > >> invasive mirror would be to rsync the central repo periodically and > >> then modify internal DNS to point 'repo1.maven.org' to an internal > >> IP address. You can save a lot of bandwidth and time this way. > >> > >> -Nathan > >> > >> -Original Message- > >> From: 陈思淼 [mailto:[EMAIL PROTECTED] > >> Sent: Friday, September 26, 2008 10:47 AM > >> To: Maven Users List > >> Subject: Re: Are we blocked by central Maven repo? > >> > >> we didn't do that kind of thing. we have a company-level artifactory > >> repository.someone didn't follow the rule but most of us are good > >> citizen, > >> and follow the maven RULE, > >> Is maven block strategy to block IP too strict? > >> Can I do anything to Fix it Up? > >> > >> > >> > >> 2008/9/26 Wayne Fay <[EMAIL PROTECTED]> > >> > >>> It is possible to get blocked if you are acting as a bad citizen > >>>
Re: Are we blocked by central Maven repo?
One thing I keep thinking about doing is creating a public mirror that is synced from central (it's a public mirror, thus, they would allow that), but provide rsync acess on some sort of paid agreement. Maybe $5/month or possibly just a ontime $100 setup fee or similar. Basically, enough to cover the bandwidth/hosting charges plus deter "everyone and their mother" from just rsyncing away.Is that something that people would have interest in? If I only had the time to get it setup... :-( Dan On Monday 29 September 2008 10:21:54 am Beyer,Nathan wrote: > What would you suggest then? Anything that requires customized maven > installs or modifying 'settings.xml' post install is not feasible in our > environment - development is too distributed. > > In the long-run I believe the rsync approach does reduce bandwith, but more > importantly, the concurrent access to the central repo via HTTP is close to > nil. > > Additionally, as I mentioned, the repository managers are NOT stable and > require too much configuration and setup. These are not acceptable options. > The repository managers aren't providing any other value beyond central > repo caching for us. > > If you're going to cut off anonymous rsync access, you might as well just > kill anonymous central repo access too, as that's the only way you'll be > able to force people into use repository managers. > > I would suggest more granular rsync access, so that requests can be more > targeted. > > -Nathan > > -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: Friday, September 26, 2008 3:51 PM > To: Maven Users List > Subject: Re: Are we blocked by central Maven repo? > > On 26-Sep-08, at 9:31 PM, Beyer,Nathan wrote: > > I disagree. 10gb or even 20gb isn't that much data, and rsync isn't > > pulling that same amount down every time it runs. We're doing it and > > it's working quite well. It's much more stable and reliable than any > > other current mirroring practices. The internal DNS modification > > makes user setup easy, since there isn't any. The use of mirror > > settings per device is a non-starter for large, disparate > > organizations. All of the various caching servers just aren't stable > > enough yet, in my opinion. > > > > It is possible to get blocked by the central repo - we were > > contacted about our significant usage and told we were on the verge > > of being blacklisted, which is what lead us to rsync the mirror. > > There is no way you could use less bandwidth rsyncing then using a > repository manager. If everyone rsynced and we allowed that against > central we would get destroyed. We only allow mirrors to rsync, not > users and mirrors will probably also stop providing rsync access > because the first hit is just too high now if everyone did it. > > > -Nathan > > > > -Original Message- > > From: Wayne Fay [mailto:[EMAIL PROTECTED] > > Sent: Friday, September 26, 2008 11:11 AM > > To: Maven Users List > > Subject: Re: Are we blocked by central Maven repo? > > > > IIRC Central is well over 10gb at this point (possibly 20gb) and a > > given organization will really only use at the most 1gb of it, so > > rsync'ing it is just a bad idea unless you are setting up an actual > > external mirror that will be available to the community. > > > > They are already using Artifactory, and I certainly hope/assume they > > are caching the results. This would limit their use of Central to one > > access per artifact (GAV) plus some hits by people not using their > > Artifactory instance. > > > > I would generally doubt they are actually blocked by Central, but > > rather this is an intermittent failure that will eventually resolve > > itself. > > > > Wayne > > > > 2008/9/26 Beyer,Nathan <[EMAIL PROTECTED]>: > >> It's possible that from the central repo's perspective, all traffic > >> from your company may seem like it's coming from one IP address > >> because of NAT. > >> > >> Using an internal mirror can help alleviate things. The most non- > >> invasive mirror would be to rsync the central repo periodically and > >> then modify internal DNS to point 'repo1.maven.org' to an internal > >> IP address. You can save a lot of bandwidth and time this way. > >> > >> -Nathan > >> > >> -Original Message- > >> From: 陈思淼 [mailto:[EMAIL PROTECTED] > >> Sent: Friday, September 26, 2008 10:47 AM > >> To: Maven Users List > >> Subject: Re: Are we blocked by central Maven repo? > >> > >> we didn't do that kind of thing. we have a company-level artifactory > >> repository.someone didn't follow the rule but most of us are good > >> citizen, > >> and follow the maven RULE, > >> Is maven block strategy to block IP too strict? > >> Can I do anything to Fix it Up? > >> > >> > >> > >> 2008/9/26 Wayne Fay <[EMAIL PROTECTED]> > >> > >>> It is possible to get blocked if you are acting as a bad citizen > >>> (downloading the entire Central repo using wget, for example). Have > >>> you (or someone else at your
RE: Are we blocked by central Maven repo?
What would you suggest then? Anything that requires customized maven installs
or modifying 'settings.xml' post install is not feasible in our environment -
development is too distributed.
In the long-run I believe the rsync approach does reduce bandwith, but more
importantly, the concurrent access to the central repo via HTTP is close to nil.
Additionally, as I mentioned, the repository managers are NOT stable and
require too much configuration and setup. These are not acceptable options. The
repository managers aren't providing any other value beyond central repo
caching for us.
If you're going to cut off anonymous rsync access, you might as well just kill
anonymous central repo access too, as that's the only way you'll be able to
force people into use repository managers.
I would suggest more granular rsync access, so that requests can be more
targeted.
-Nathan
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Friday, September 26, 2008 3:51 PM
To: Maven Users List
Subject: Re: Are we blocked by central Maven repo?
On 26-Sep-08, at 9:31 PM, Beyer,Nathan wrote:
> I disagree. 10gb or even 20gb isn't that much data, and rsync isn't
> pulling that same amount down every time it runs. We're doing it and
> it's working quite well. It's much more stable and reliable than any
> other current mirroring practices. The internal DNS modification
> makes user setup easy, since there isn't any. The use of mirror
> settings per device is a non-starter for large, disparate
> organizations. All of the various caching servers just aren't stable
> enough yet, in my opinion.
>
> It is possible to get blocked by the central repo - we were
> contacted about our significant usage and told we were on the verge
> of being blacklisted, which is what lead us to rsync the mirror.
>
There is no way you could use less bandwidth rsyncing then using a
repository manager. If everyone rsynced and we allowed that against
central we would get destroyed. We only allow mirrors to rsync, not
users and mirrors will probably also stop providing rsync access
because the first hit is just too high now if everyone did it.
> -Nathan
>
> -Original Message-
> From: Wayne Fay [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 26, 2008 11:11 AM
> To: Maven Users List
> Subject: Re: Are we blocked by central Maven repo?
>
> IIRC Central is well over 10gb at this point (possibly 20gb) and a
> given organization will really only use at the most 1gb of it, so
> rsync'ing it is just a bad idea unless you are setting up an actual
> external mirror that will be available to the community.
>
> They are already using Artifactory, and I certainly hope/assume they
> are caching the results. This would limit their use of Central to one
> access per artifact (GAV) plus some hits by people not using their
> Artifactory instance.
>
> I would generally doubt they are actually blocked by Central, but
> rather this is an intermittent failure that will eventually resolve
> itself.
>
> Wayne
>
> 2008/9/26 Beyer,Nathan <[EMAIL PROTECTED]>:
>> It's possible that from the central repo's perspective, all traffic
>> from your company may seem like it's coming from one IP address
>> because of NAT.
>>
>> Using an internal mirror can help alleviate things. The most non-
>> invasive mirror would be to rsync the central repo periodically and
>> then modify internal DNS to point 'repo1.maven.org' to an internal
>> IP address. You can save a lot of bandwidth and time this way.
>>
>> -Nathan
>>
>> -Original Message-
>> From: 陈思淼 [mailto:[EMAIL PROTECTED]
>> Sent: Friday, September 26, 2008 10:47 AM
>> To: Maven Users List
>> Subject: Re: Are we blocked by central Maven repo?
>>
>> we didn't do that kind of thing. we have a company-level artifactory
>> repository.someone didn't follow the rule but most of us are good
>> citizen,
>> and follow the maven RULE,
>> Is maven block strategy to block IP too strict?
>> Can I do anything to Fix it Up?
>>
>>
>>
>> 2008/9/26 Wayne Fay <[EMAIL PROTECTED]>
>>
>>> It is possible to get blocked if you are acting as a bad citizen
>>> (downloading the entire Central repo using wget, for example). Have
>>> you (or someone else at your company) attempted to do this from your
>>> IP address?
>>>
>>> If not, the repo is probably just busy, or you had some random
>>> Internet connection failure. Try again. "Normal" Maven usage of the
>>> repo will not get you blocked.
>>>
>>> Wayne
>>>
>>> On Fri, Sep 26, 2008 at 7:37 AM, 陈思淼 <[EMAIL PROTECTED]>
>>> wrote:
This's log from artifactory.
2008-09-26 22:27:28,025 [WARN ] (RemoteRepoBase.java:259{10}) -
>>> repo1:
Error in getting information for 'org/apache/maven
/maven-model/2.0.4/maven-model-2.0.4.pom.sha1'
(org.apache.commons.httpclient.ConnectionPoolTimeoutException:
Timeout
waiting
for connection).
we company only have one outlet IP address
RE: how to set '/' as root context for war?
Geoffrey Wiseman wrote: > > On Fri, Sep 26, 2008 at 7:29 PM, Mick Knutson <[EMAIL PROTECTED]>wrote: > > > I want to set my war to have a root context of '/' instead of 'mywarname/' > > > > I can't remember how to set this and would appreciate a refresher. > > > > That's configuration in the application server, usually -- completely unrelated to Maven, unless you're talking about, say, making >that happen in the Maven cargo plugin. > - Geoffrey Unless you're using EAR files, in which case it's pretty trivial (and documented!). See http://maven.apache.org/plugins/maven-ear-plugin/examples/customizing-co ntext-root.html. There is no standard mechanism for specifying a context root of a standalone WAR deployment (i.e. outside of an EAR deployment). Justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
creating a project
Hi guys, I use this command from the archetype plugin: Mvn archetype:create -DarchetpeGroupId=org.apache.maven.archetypes \ -DarchetypeArtifactId=maven-archetype-site \ -DgroupId=com.mycompany \ -DartifactId=my-site It creates a dedicated site project where I can customize the layout and the html (via apt, faq files etc.) output stuff. How can I integrate my java sources and reports for that sources (e.g. from javadoc, checkstyle, pmd, xref...) to this site? Regards, Matthias
Re: Are we blocked by central Maven repo?
I second that.
We used to rsync the whole repo... but after the second time our internal
mirror server ran out of disk space we gave up and switched to nexus... the
whole thing is a lot more stable than the rsync nightmare... plus
we're not hitting 1/100 as much bandwith, and since we needed an internal
repo to deploy to anyway... win win win win
-Stephen
2008/9/26 Baptiste MATHUS <[EMAIL PROTECTED]>
> Rsync'ing the whole repository seems a real bad idea to me, I guess you
> could be blacklisted doing that.
> It's far better to do the downloading on demand and caching it by using a
> common maven repo manager (archiva, nexus...).
> In fact, if you mirror the whole repository, I guess you're just going to:
> * waste your bandwidth and the central repo one during a quite long time
> * waste your local disk space.
> I guess you're unlikely going to use even 5% of the thousands of existing
> artifacts from central.
>
> Well, redirecting packets to repo1.maven.org might be acceptable, though
> it's often useful to verify if the artifact is really available publicly
> before insulting your corporate repo. I do it myself quite regularly.
>
> Cheers.
>
> 2008/9/26 Beyer,Nathan <[EMAIL PROTECTED]>
>
> > It's possible that from the central repo's perspective, all traffic from
> > your company may seem like it's coming from one IP address because of
> NAT.
> >
> > Using an internal mirror can help alleviate things. The most non-invasive
> > mirror would be to rsync the central repo periodically and then modify
> > internal DNS to point 'repo1.maven.org' to an internal IP address. You
> can
> > save a lot of bandwidth and time this way.
> >
> > -Nathan
> >
> > -Original Message-
> > From: 陈思淼 [mailto:[EMAIL PROTECTED]
> > Sent: Friday, September 26, 2008 10:47 AM
> > To: Maven Users List
> > Subject: Re: Are we blocked by central Maven repo?
> >
> > we didn't do that kind of thing. we have a company-level artifactory
> > repository.someone didn't follow the rule but most of us are good
> citizen,
> > and follow the maven RULE,
> > Is maven block strategy to block IP too strict?
> > Can I do anything to Fix it Up?
> >
> >
> >
> > 2008/9/26 Wayne Fay <[EMAIL PROTECTED]>
> >
> > > It is possible to get blocked if you are acting as a bad citizen
> > > (downloading the entire Central repo using wget, for example). Have
> > > you (or someone else at your company) attempted to do this from your
> > > IP address?
> > >
> > > If not, the repo is probably just busy, or you had some random
> > > Internet connection failure. Try again. "Normal" Maven usage of the
> > > repo will not get you blocked.
> > >
> > > Wayne
> > >
> > > On Fri, Sep 26, 2008 at 7:37 AM, 陈思淼 <[EMAIL PROTECTED]> wrote:
> > > > This's log from artifactory.
> > > >
> > > > 2008-09-26 22:27:28,025 [WARN ] (RemoteRepoBase.java:259{10}) -
> > > repo1:
> > > > Error in getting information for 'org/apache/maven
> > > > /maven-model/2.0.4/maven-model-2.0.4.pom.sha1'
> > > > (org.apache.commons.httpclient.ConnectionPoolTimeoutException:
> Timeout
> > > > waiting
> > > > for connection).
> > > >
> > > > we company only have one outlet IP address ,someone may download
> Maven
> > > from
> > > > apache and didn't set the Mirror of central in the conf/setting.xml.
> so
> > > they
> > > > download the pom directly from central? Is that the reason why the
> > > central
> > > > repo block our IP address?
> > > >
> > >
> >
> > --
> > CONFIDENTIALITY NOTICE This message and any included attachments are from
> > Cerner Corporation and are intended only for the addressee. The
> information
> > contained in this message is confidential and may constitute inside or
> > non-public information under international, federal, or state securities
> > laws. Unauthorized forwarding, printing, copying, distribution, or use of
> > such information is strictly prohibited and may be unlawful. If you are
> not
> > the addressee, please promptly delete this message and notify the sender
> of
> > the delivery error by e-mail or you may call Cerner's corporate offices
> in
> > Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Baptiste MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>
Re: copy libraries to classpath
yeah i red that too. but i thought this would refer to the
configuration-section of the plugin :-S
cheers
norbert
Nick Stolwijk schrieb:
I think the outputDirectory is ignored because of the ArtifactItem
(whatever that may be... ;) )
>From the documentation:
outputDirectory :
Default location used for mojo unless overridden in ArtifactItem
* Type: java.io.File
* Since: 1.0
* Required: No
* Expression: ${outputDirectory}
* Default: ${project.build.directory}/dependency
Hth,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Mon, Sep 29, 2008 at 3:01 PM, Norbert Lazzeri <[EMAIL PROTECTED]> wrote:
using the maven-dependency-plugin with:
org.apache.maven.plugins
maven-dependency-plugin
copy-dependencies
package
copy-dependencies
${project.build.directory}/lib
false
false
true
like suggested on the plugin-homepage all dependencies are copied to
targed/dependencies. why is the outputDirectory ignored?
cheers,
Norbert
Norbert Lazzeri schrieb:
Hi,
is it possible to let maven copy all dependencies to my classpath?
my jar-configuration looks like:
org.apache.maven.plugins
maven-jar-plugin
true
lib/
uboot.App
so it would be nice if maven would create a lib-directory and copy all
jars in to it since there are plenty of them and doing this by hand is
troublesome
cheers,
Norbert
-
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: copy libraries to classpath
I think the outputDirectory is ignored because of the ArtifactItem
(whatever that may be... ;) )
>From the documentation:
outputDirectory :
Default location used for mojo unless overridden in ArtifactItem
* Type: java.io.File
* Since: 1.0
* Required: No
* Expression: ${outputDirectory}
* Default: ${project.build.directory}/dependency
Hth,
Nick Stolwijk
~Java Developer~
Iprofs BV.
Claus Sluterweg 125
2012 WS Haarlem
www.iprofs.nl
On Mon, Sep 29, 2008 at 3:01 PM, Norbert Lazzeri <[EMAIL PROTECTED]> wrote:
> using the maven-dependency-plugin with:
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> copy-dependencies
> package
>
> copy-dependencies
>
>
>
> ${project.build.directory}/lib
> false
> false
> true
>
>
>
>
>
> like suggested on the plugin-homepage all dependencies are copied to
> targed/dependencies. why is the outputDirectory ignored?
>
> cheers,
> Norbert
>
> Norbert Lazzeri schrieb:
>>
>> Hi,
>>
>> is it possible to let maven copy all dependencies to my classpath?
>>
>> my jar-configuration looks like:
>>
>> org.apache.maven.plugins
>> maven-jar-plugin
>>
>>
>>
>> true
>> lib/
>> uboot.App
>>
>>
>>
>>
>>
>> so it would be nice if maven would create a lib-directory and copy all
>> jars in to it since there are plenty of them and doing this by hand is
>> troublesome
>>
>> cheers,
>> Norbert
>>
>> -
>> 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: Plugin inheritance
You would do something like this: three See http://www.ejlife.net/blogs/buildchimp/2007/06/07/1181254122408.html Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Mon, Sep 29, 2008 at 3:05 PM, Stephen Connolly <[EMAIL PROTECTED]> wrote: > There is an attribute that you can specify to indicate that you are > appending elements rather than replacing... if only I could remember it! > > 2008/9/29 tjunak <[EMAIL PROTECTED]> > >> >> I've checked it again - every time a whole list is overriden not elements >> on >> the list. >> I have made few tries on different plugins - and the result is always the >> same. >> >> I have dozens of child-pom where their configuration in many cases differ a >> little. >> It looks that it is needed to move whole configuration from Parent-Pom into >> every child pom that need even a slight change in configuration (one extra >> element on the list). I hoped to keep common settings in Parent-Pom and >> that I could add specific options in some child-poms. But then in that case >> it is very hard to maintain - especially in a corporate level projects. >> >> Isn't it a bug? >> >> How does the merging work in Maven in case of list structure ? >> >> Thank you for any help! >> >> >> Baptiste MATHUS-4 wrote: >> > >> > Hi, >> > >> > You should try node to manage this, see >> > http://maven.apache.org/pom.html#Plugin_Management. >> > >> > Cheers. >> > >> > 2008/9/25 tjunak <[EMAIL PROTECTED]> >> > >> >> >> >> Hi, >> >> >> >> I have a following problem with plugin inheritance. >> >> >> >> I have put a plugin with lot of configuration in Parent-Pom, there are >> >> lot >> >> of child-poms in the project. >> >> Most of them use the plugin configuration but in some cases I have to >> >> re-define some options. >> >> Let's say: >> >> >> >> Parent-Pom: >> >> >> >> >> >> my-plugin >> >> >> >> >> >> >> >> >> >> def-A >> >> def-B >> >> >> >> >> >> >> >> >> >> >> >> >> >> In my real project there are much more such lists and elements. >> >> >> >> >> >> >> >> Child-Pom: >> >> >> >> Here I have to add some special define: >> >> >> >> >> >> my-plugin >> >> >> >> >> >> >> >> >> >> def-C >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> The problem is that when I'm checking this with help:effective-pom I get >> >> only this: >> >> >> >> >> >> def-C >> >> >> >> >> >> which means whole list is overriden not elements on the list. >> >> >> >> My expectation is to get: >> >> >> >> >> >> def-A >> >> def-B >> >> def-C >> >> >> >> >> >> This causes that in a lot of child-poms I have re-write almost all >> >> configuration from Parent-Pom which >> >> of course will be later hard to maintain. >> >> >> >> Is there a way to inherit it on list elements level with Maven ? >> >> >> >> Thank you in advance! >> >> -- >> >> View this message in context: >> >> http://www.nabble.com/Plugin-inheritance-tp19664782p19664782.html >> >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> >> >> >> - >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > >> > -- >> > Baptiste MATHUS - http://batmat.net >> > Sauvez un arbre, >> > Mangez un castor ! >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Plugin-inheritance-tp19664782p19722688.html >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> - >> 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: Plugin inheritance
There is an attribute that you can specify to indicate that you are appending elements rather than replacing... if only I could remember it! 2008/9/29 tjunak <[EMAIL PROTECTED]> > > I've checked it again - every time a whole list is overriden not elements > on > the list. > I have made few tries on different plugins - and the result is always the > same. > > I have dozens of child-pom where their configuration in many cases differ a > little. > It looks that it is needed to move whole configuration from Parent-Pom into > every child pom that need even a slight change in configuration (one extra > element on the list). I hoped to keep common settings in Parent-Pom and > that I could add specific options in some child-poms. But then in that case > it is very hard to maintain - especially in a corporate level projects. > > Isn't it a bug? > > How does the merging work in Maven in case of list structure ? > > Thank you for any help! > > > Baptiste MATHUS-4 wrote: > > > > Hi, > > > > You should try node to manage this, see > > http://maven.apache.org/pom.html#Plugin_Management. > > > > Cheers. > > > > 2008/9/25 tjunak <[EMAIL PROTECTED]> > > > >> > >> Hi, > >> > >> I have a following problem with plugin inheritance. > >> > >> I have put a plugin with lot of configuration in Parent-Pom, there are > >> lot > >> of child-poms in the project. > >> Most of them use the plugin configuration but in some cases I have to > >> re-define some options. > >> Let's say: > >> > >> Parent-Pom: > >> > >> > >> my-plugin > >> > >> > >> > >> > >> def-A > >> def-B > >> > >> > >> > >> > >> > >> > >> In my real project there are much more such lists and elements. > >> > >> > >> > >> Child-Pom: > >> > >> Here I have to add some special define: > >> > >> > >> my-plugin > >> > >> > >> > >> > >> def-C > >> > >> > >> > >> > >> > >> > >> > >> The problem is that when I'm checking this with help:effective-pom I get > >> only this: > >> > >> > >> def-C > >> > >> > >> which means whole list is overriden not elements on the list. > >> > >> My expectation is to get: > >> > >> > >> def-A > >> def-B > >> def-C > >> > >> > >> This causes that in a lot of child-poms I have re-write almost all > >> configuration from Parent-Pom which > >> of course will be later hard to maintain. > >> > >> Is there a way to inherit it on list elements level with Maven ? > >> > >> Thank you in advance! > >> -- > >> View this message in context: > >> http://www.nabble.com/Plugin-inheritance-tp19664782p19664782.html > >> Sent from the Maven - Users mailing list archive at Nabble.com. > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > > Baptiste MATHUS - http://batmat.net > > Sauvez un arbre, > > Mangez un castor ! > > > > > > -- > View this message in context: > http://www.nabble.com/Plugin-inheritance-tp19664782p19722688.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: mirrors, oh mirrors
>The point of mirrors is to provide an alternate location for the content. I'd like mirrors to provide multiple alternate locations. I put the improvement request here: http://jira.codehaus.org/browse/MNG-3772 Cheers, Szczepan On Mon, Sep 29, 2008 at 1:41 PM, Jörg Schaible <[EMAIL PROTECTED]> wrote: > szczepiq wrote: >> Hi all, >> >> Mirrors are giving me headache recently. See this: >> >> >> >> corporate-repo >> corporate-repo-backup >> ... >> * >> >> >> corporate-repo-backup >> corporate-repo-backup >> ... >> * >> >> >> >> Above configuration is a dead simple fail-over system. If >> corporate-repo is down, I want the corporate-repo-backup to mirror >> everything. Unfortunately it doesn't work :( It seems only last mirror >> is active when "mirrorOf" property is the same. Is this how it suppose >> to work? After all, the point of mirrors is to provide multiple >> locations for the same content, isn't it? Any input? > > The point of mirrors is to provide an alternate location for the content. > This does not imply fallback. You can use for quite some OS organizations > mirrors of their content (Apache, SF,net, ...), however, if you select a > mirror and it is not available or out of date and your file is not found, > you're also not automagically redirected to a different one, that is > available and in sync. > > - 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]
Re: copy libraries to classpath
using the maven-dependency-plugin with:
org.apache.maven.plugins
maven-dependency-plugin
copy-dependencies
package
copy-dependencies
${project.build.directory}/lib
false
false
true
like suggested on the plugin-homepage all dependencies are copied to
targed/dependencies. why is the outputDirectory ignored?
cheers,
Norbert
Norbert Lazzeri schrieb:
Hi,
is it possible to let maven copy all dependencies to my classpath?
my jar-configuration looks like:
org.apache.maven.plugins
maven-jar-plugin
true
lib/
uboot.App
so it would be nice if maven would create a lib-directory and copy all
jars in to it since there are plenty of them and doing this by hand is
troublesome
cheers,
Norbert
-
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: how to set '/' as root context for war?
On Fri, Sep 26, 2008 at 7:29 PM, Mick Knutson <[EMAIL PROTECTED]>wrote: > I want to set my war to have a root context of '/' instead of 'mywarname/' > > I can't remember how to set this and would appreciate a refresher. > That's configuration in the application server, usually -- completely unrelated to Maven, unless you're talking about, say, making that happen in the Maven cargo plugin. - Geoffrey -- Geoffrey Wiseman
Re: how to set '/' as root context for war?
This is a deployment option, dependent on your container. Unless you are referring to the Jetty Maven plugin, I don't believe there's anything in the WAR packaging process in Maven that affects this. - Brett 2008/9/27 Mick Knutson <[EMAIL PROTECTED]>: > I want to set my war to have a root context of '/' instead of 'mywarname/' > > I can't remember how to set this and would appreciate a refresher. > > -- > --- > Thank You… > > Mick Knutson > BASE Logic, inc. > (415) 354-4215 > > Website: http://baselogic.com > Blog: http://baselogic.com/blog > BLiNC Magazine: http://blincmagazine.com > Linked IN: http://linkedin.com/in/mickknutson > DJ Mick: http://djmick.com > MySpace: http://myspace.com/mickknutson > Vacation Rental: http://tahoe.baselogic.com > -- Brett Porter Blog: http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Are we blocked by central Maven repo?
First might be that you privately ask Jason if you are concerned by
http://blogs.sonatype.com/jvanzyl/2008/08/28/1219948661495.html
If so, then beg his pardon and promise you won't do it again, never :-).
But before annoying Jason, obviously try wget'ing something from
repo1.maven.org from your corporate maven repository server.
Cheers.
2008/9/26 陈思淼 <[EMAIL PROTECTED]>
> we didn't do that kind of thing. we have a company-level artifactory
> repository.someone didn't follow the rule but most of us are good citizen,
> and follow the maven RULE,
> Is maven block strategy to block IP too strict?
> Can I do anything to Fix it Up?
>
>
>
> 2008/9/26 Wayne Fay <[EMAIL PROTECTED]>
>
> > It is possible to get blocked if you are acting as a bad citizen
> > (downloading the entire Central repo using wget, for example). Have
> > you (or someone else at your company) attempted to do this from your
> > IP address?
> >
> > If not, the repo is probably just busy, or you had some random
> > Internet connection failure. Try again. "Normal" Maven usage of the
> > repo will not get you blocked.
> >
> > Wayne
> >
> > On Fri, Sep 26, 2008 at 7:37 AM, 陈思淼 <[EMAIL PROTECTED]> wrote:
> > > This's log from artifactory.
> > >
> > > 2008-09-26 22:27:28,025 [WARN ] (RemoteRepoBase.java:259{10}) -
> > repo1:
> > > Error in getting information for 'org/apache/maven
> > > /maven-model/2.0.4/maven-model-2.0.4.pom.sha1'
> > > (org.apache.commons.httpclient.ConnectionPoolTimeoutException: Timeout
> > > waiting
> > > for connection).
> > >
> > > we company only have one outlet IP address ,someone may download Maven
> > from
> > > apache and didn't set the Mirror of central in the conf/setting.xml. so
> > they
> > > download the pom directly from central? Is that the reason why the
> > central
> > > repo block our IP address?
> > >
> >
>
--
Baptiste MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
Re: Are we blocked by central Maven repo?
Rsync'ing the whole repository seems a real bad idea to me, I guess you
could be blacklisted doing that.
It's far better to do the downloading on demand and caching it by using a
common maven repo manager (archiva, nexus...).
In fact, if you mirror the whole repository, I guess you're just going to:
* waste your bandwidth and the central repo one during a quite long time
* waste your local disk space.
I guess you're unlikely going to use even 5% of the thousands of existing
artifacts from central.
Well, redirecting packets to repo1.maven.org might be acceptable, though
it's often useful to verify if the artifact is really available publicly
before insulting your corporate repo. I do it myself quite regularly.
Cheers.
2008/9/26 Beyer,Nathan <[EMAIL PROTECTED]>
> It's possible that from the central repo's perspective, all traffic from
> your company may seem like it's coming from one IP address because of NAT.
>
> Using an internal mirror can help alleviate things. The most non-invasive
> mirror would be to rsync the central repo periodically and then modify
> internal DNS to point 'repo1.maven.org' to an internal IP address. You can
> save a lot of bandwidth and time this way.
>
> -Nathan
>
> -Original Message-
> From: 陈思淼 [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 26, 2008 10:47 AM
> To: Maven Users List
> Subject: Re: Are we blocked by central Maven repo?
>
> we didn't do that kind of thing. we have a company-level artifactory
> repository.someone didn't follow the rule but most of us are good citizen,
> and follow the maven RULE,
> Is maven block strategy to block IP too strict?
> Can I do anything to Fix it Up?
>
>
>
> 2008/9/26 Wayne Fay <[EMAIL PROTECTED]>
>
> > It is possible to get blocked if you are acting as a bad citizen
> > (downloading the entire Central repo using wget, for example). Have
> > you (or someone else at your company) attempted to do this from your
> > IP address?
> >
> > If not, the repo is probably just busy, or you had some random
> > Internet connection failure. Try again. "Normal" Maven usage of the
> > repo will not get you blocked.
> >
> > Wayne
> >
> > On Fri, Sep 26, 2008 at 7:37 AM, 陈思淼 <[EMAIL PROTECTED]> wrote:
> > > This's log from artifactory.
> > >
> > > 2008-09-26 22:27:28,025 [WARN ] (RemoteRepoBase.java:259{10}) -
> > repo1:
> > > Error in getting information for 'org/apache/maven
> > > /maven-model/2.0.4/maven-model-2.0.4.pom.sha1'
> > > (org.apache.commons.httpclient.ConnectionPoolTimeoutException: Timeout
> > > waiting
> > > for connection).
> > >
> > > we company only have one outlet IP address ,someone may download Maven
> > from
> > > apache and didn't set the Mirror of central in the conf/setting.xml. so
> > they
> > > download the pom directly from central? Is that the reason why the
> > central
> > > repo block our IP address?
> > >
> >
>
> --
> CONFIDENTIALITY NOTICE This message and any included attachments are from
> Cerner Corporation and are intended only for the addressee. The information
> contained in this message is confidential and may constitute inside or
> non-public information under international, federal, or state securities
> laws. Unauthorized forwarding, printing, copying, distribution, or use of
> such information is strictly prohibited and may be unlawful. If you are not
> the addressee, please promptly delete this message and notify the sender of
> the delivery error by e-mail or you may call Cerner's corporate offices in
> Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Baptiste MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
how to set '/' as root context for war?
I want to set my war to have a root context of '/' instead of 'mywarname/' I can't remember how to set this and would appreciate a refresher. -- --- Thank You… Mick Knutson BASE Logic, inc. (415) 354-4215 Website: http://baselogic.com Blog: http://baselogic.com/blog BLiNC Magazine: http://blincmagazine.com Linked IN: http://linkedin.com/in/mickknutson DJ Mick: http://djmick.com MySpace: http://myspace.com/mickknutson Vacation Rental: http://tahoe.baselogic.com
Re: Cannot run program "env"
Does maven have enough memory allocated? Looks like the virtual server does not have the minimum for maven to run. 128mb is the min I think. On Sun, Sep 28, 2008 at 8:10 AM, greeklinux <[EMAIL PROTECTED]> wrote: > > Hello, > > I am using maven, and I setup an CI system on a virtual server. > When the build process starts, maven fails with the > following error: > > Parsing POMs > ERROR: Failed to parse POMs > java.io.IOException: Cannot run program "env": java.io.IOException: > error=12, Cannot allocate memory >at java.lang.ProcessBuilder.start(ProcessBuilder.java:459) >at java.lang.Runtime.exec(Runtime.java:593) >at java.lang.Runtime.exec(Runtime.java:431) >at java.lang.Runtime.exec(Runtime.java:328) >at > > org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:250) >at > > org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:216) >at > > org.apache.maven.project.interpolation.RegexBasedModelInterpolator.(RegexBasedModelInterpolator.java:63) >at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) >at > > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >at > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >at java.lang.reflect.Constructor.newInstance(Constructor.java:513) >at java.lang.Class.newInstance0(Class.java:355) >at java.lang.Class.newInstance(Class.java:308) >at > > org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:44) >at > > org.codehaus.plexus.DefaultPlexusContainer.createComponentInstance(DefaultPlexusContainer.java:1464) >at > > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:93) >at > > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) >at > > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) >at > > org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:129) >at > > org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent(FieldComponentComposer.java:73) >at > > org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:68) >at > > org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexusContainer.java:1486) >at > > org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:29) >at > > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) >at > > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) >at > > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) >at > > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) >at > > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) >at org.codehaus.plexus.embed.Embedder.lookup(Embedder.java:78) >at hudson.maven.MavenEmbedder.start(MavenEmbedder.java:655) >at hudson.maven.MavenUtil.createEmbedder(MavenUtil.java:75) >at > hudson.tasks.Maven$MavenInstallation.createEmbedder(Maven.java:337) >at > > hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:691) >at > > hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:640) >at hudson.FilePath.act(FilePath.java:363) >at > > hudson.maven.MavenModuleSetBuild$RunnerImpl.parsePoms(MavenModuleSetBuild.java:390) >at > > hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:285) >at > hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:240) >at hudson.model.Run.run(Run.java:793) >at > hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:205) >at > hudson.model.ResourceController.execute(ResourceController.java:70) >at hudson.model.Executor.run(Executor.java:88) > Caused by: java.io.IOException: java.io.IOException: error=12, Cannot > allocate memory >at java.lang.UNIXProcess.(UNIXProcess.java:148) >at java.lang.ProcessImpl.start(ProcessImpl.java:65) >at java.lang.ProcessBuilder.start(ProcessBuilder.java:452) >... 41 more > > > Is this because maven cannot create a new process? Or some other problem? > > Thanks > > -- > View this message in context: > http://www.na
copy libraries to classpath
Hi, is it possible to let maven copy all dependencies to my classpath? my jar-configuration looks like: org.apache.maven.plugins maven-jar-plugin true lib/ uboot.App so it would be nice if maven would create a lib-directory and copy all jars in to it since there are plenty of them and doing this by hand is troublesome cheers, Norbert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with path in pom (windows)
I actually set my local repo in my settings.xml to C:\opt\.m2 to avoid spaces. On Sun, Sep 28, 2008 at 7:52 AM, Wendy Smoak <[EMAIL PROTECTED]> wrote: > On Sun, Sep 28, 2008 at 4:28 AM, Matthias Dorfner > <[EMAIL PROTECTED]> wrote: > > > I tried to integrate umlgraph to my pom. It looks as following: > > C:\Dokumente und > > > Einstellungen\Matty\.m2\repository\UMLGraph-5.1\lib\UmlGraph.jar > > Most likely the spaces in the path are causing problems. > > The best bet is to install the jar into your local repository using > "mvn install:install-file", and then use docletArtifact instead of > docletPath, as shown here: > > > http://maven.apache.org/plugins/maven-javadoc-plugin/examples/alternate-doclet.html > > The UMLGraph artifacts belong in groupId=gr.spinellis and > artifactId=UmlGraph , see > http://repo1.maven.org/maven2/gr/spinellis/UmlGraph/ > > (Adding arbitrary paths to ~/.m2/repository as you've done, apparently > by unpacking the UMLGraph distribution, isn't recommended. The local > repository has a specific format.) > > If you are working with a team and have a shared (internal) "remote" > repository, then deploy the artifact there instead, and/or submit it > for upload to the central repo. > > -- > Wendy > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- --- Thank You… Mick Knutson BASE Logic, inc. (415) 354-4215 Website: http://baselogic.com Blog: http://baselogic.com/blog BLiNC Magazine: http://blincmagazine.com Linked IN: http://linkedin.com/in/mickknutson DJ Mick: http://djmick.com MySpace: http://myspace.com/mickknutson Vacation Rental: http://tahoe.baselogic.com
Re: repository for youtube api
Hi, Have you already chosen the youtube API you're gonna use? Maven can't replace that. You won't choose a given library because it's available in some maven repo. You'll choose it 'cause it matches your needs. And if it's well-known, then there's chances that it's already present in some repo. Maybe google could be your friend... After 10 seconds of research: http://code.google.com/p/gdata-java-client/ It seems like it's not present in repo1 or google maven repository, so if this lib suits your needs, you might have to: * install it locally (or deploy in your corporate maven repo) * File an issue in the project ( http://code.google.com/p/gdata-java-client/issues/entry) to require a maven deployment Cheers. 2008/9/29 Angelo Chen <[EMAIL PROTECTED]> > > Hi, > > I need to use youtube api in my 'mavenized' app, is there a youtube > dependency somewhere? thanks. > > A.C. > -- > View this message in context: > http://www.nabble.com/repository-for-youtube-api-tp19719346p19719346.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Accessing project version number from Java
On 29 Sep 2008, at 13:22, Mark Hobson wrote:
2008/9/29 Dominic Mitchell <[EMAIL PROTECTED]>:
What's the easiest way to get at the version number in the POM from
Java?
I've been using
getResourceAsStream('META-INF/maven/groupId/artifactId/
pom.properties');
But this doesn't work while I'm developing in Eclipse (only when
using the
built jar file).
You can use maven-runtime to dynamically obtain this information, but
it still has the limitation of requiring the META-INF files created at
package-time:
http://maven.apache.org/shared/maven-runtime/
Aha! Thanks for pointing this out. That's much more useful than
rolling my own implementation of such a thing.
I'd quite like to see the generation of these metadata files occur at
the generate-resources phase of the lifecycle which would allow it
work within the IDE too.
-Dom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing project version number from Java
On 29 Sep 2008, at 13:08, Brett Porter wrote:
2008/9/29 Dominic Mitchell <[EMAIL PROTECTED]>:
What's the easiest way to get at the version number in the POM from
Java?
I've been using
getResourceAsStream('META-INF/maven/groupId/artifactId/
pom.properties');
But this doesn't work while I'm developing in Eclipse (only when
using the
built jar file).
Yes, this is only generated when the JAR is packaged. It might be best
for your test cases to substitute in a known value here rather than
relying on it, unless you are doing something specific with the
version.
There's nothing particularly important about this — it's just a minor
annoyance. We already substitute "[dev]" if we can't read it.
Ideally, I'd like to somehow generate a Java class which contains the
version number. I thought I should be able to do this using resource
filtering, but I couldn't see a way to configure the resources
plugin to
achieve this…
@project.version@ should be substituted in a copy, but resources are
processed after compilation so the timing is not correct. You'd need
to execute a specific plugin in the generate-sources phase.
I'll have a play with this to see if I can get it to do what I want.
Thanks for your quick response!
-Dom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing project version number from Java
2008/9/29 Dominic Mitchell <[EMAIL PROTECTED]>:
> What's the easiest way to get at the version number in the POM from Java?
>
> I've been using
> getResourceAsStream('META-INF/maven/groupId/artifactId/pom.properties');
> But this doesn't work while I'm developing in Eclipse (only when using the
> built jar file).
>
> Ideally, I'd like to somehow generate a Java class which contains the
> version number. I thought I should be able to do this using resource
> filtering, but I couldn't see a way to configure the resources plugin to
> achieve this…
>
> Any help would be most gratefully appreciated.
You can use maven-runtime to dynamically obtain this information, but
it still has the limitation of requiring the META-INF files created at
package-time:
http://maven.apache.org/shared/maven-runtime/
I'd quite like to see the generation of these metadata files occur at
the generate-resources phase of the lifecycle which would allow it
work within the IDE too.
Cheers,
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing project version number from Java
2008/9/29 Dominic Mitchell <[EMAIL PROTECTED]>:
> What's the easiest way to get at the version number in the POM from Java?
>
> I've been using
> getResourceAsStream('META-INF/maven/groupId/artifactId/pom.properties');
> But this doesn't work while I'm developing in Eclipse (only when using the
> built jar file).
Yes, this is only generated when the JAR is packaged. It might be best
for your test cases to substitute in a known value here rather than
relying on it, unless you are doing something specific with the
version.
>
> Ideally, I'd like to somehow generate a Java class which contains the
> version number. I thought I should be able to do this using resource
> filtering, but I couldn't see a way to configure the resources plugin to
> achieve this…
@project.version@ should be substituted in a copy, but resources are
processed after compilation so the timing is not correct. You'd need
to execute a specific plugin in the generate-sources phase.
- Brett
>
> Any help would be most gratefully appreciated.
>
> Thanks,
> -Dom
--
Brett Porter
Blog: http://blogs.exist.com/bporter/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plugin inheritance
I've checked it again - every time a whole list is overriden not elements on the list. I have made few tries on different plugins - and the result is always the same. I have dozens of child-pom where their configuration in many cases differ a little. It looks that it is needed to move whole configuration from Parent-Pom into every child pom that need even a slight change in configuration (one extra element on the list). I hoped to keep common settings in Parent-Pom and that I could add specific options in some child-poms. But then in that case it is very hard to maintain - especially in a corporate level projects. Isn't it a bug? How does the merging work in Maven in case of list structure ? Thank you for any help! Baptiste MATHUS-4 wrote: > > Hi, > > You should try node to manage this, see > http://maven.apache.org/pom.html#Plugin_Management. > > Cheers. > > 2008/9/25 tjunak <[EMAIL PROTECTED]> > >> >> Hi, >> >> I have a following problem with plugin inheritance. >> >> I have put a plugin with lot of configuration in Parent-Pom, there are >> lot >> of child-poms in the project. >> Most of them use the plugin configuration but in some cases I have to >> re-define some options. >> Let's say: >> >> Parent-Pom: >> >> >> my-plugin >> >> >> >> >> def-A >> def-B >> >> >> >> >> >> >> In my real project there are much more such lists and elements. >> >> >> >> Child-Pom: >> >> Here I have to add some special define: >> >> >> my-plugin >> >> >> >> >> def-C >> >> >> >> >> >> >> >> The problem is that when I'm checking this with help:effective-pom I get >> only this: >> >> >> def-C >> >> >> which means whole list is overriden not elements on the list. >> >> My expectation is to get: >> >> >> def-A >> def-B >> def-C >> >> >> This causes that in a lot of child-poms I have re-write almost all >> configuration from Parent-Pom which >> of course will be later hard to maintain. >> >> Is there a way to inherit it on list elements level with Maven ? >> >> Thank you in advance! >> -- >> View this message in context: >> http://www.nabble.com/Plugin-inheritance-tp19664782p19664782.html >> Sent from the Maven - Users mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > Baptiste MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! > > -- View this message in context: http://www.nabble.com/Plugin-inheritance-tp19664782p19722688.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Accessing project version number from Java
What's the easiest way to get at the version number in the POM from
Java?
I've been using getResourceAsStream('META-INF/maven/groupId/artifactId/
pom.properties'); But this doesn't work while I'm developing in
Eclipse (only when using the built jar file).
Ideally, I'd like to somehow generate a Java class which contains the
version number. I thought I should be able to do this using resource
filtering, but I couldn't see a way to configure the resources plugin
to achieve this…
Any help would be most gratefully appreciated.
Thanks,
-Dom
Re: Cannot run program "env"
Can you try running it under a different user account? - Brett 2008/9/29 greeklinux <[EMAIL PROTECTED]>: > > Hello, > > thanks for the reply. > > I tried a 2.0.9 version and the 2.1 preview releases, but the error still > show up. > "Error getting environment vars for profile activation java.io.IOException: > Cannot run program "env": java.io.IOException: error=12, Cannot allocate > memory" > > I read in other posts, that there was a bug with the environment variables. > But mine are fine. > > The good thing is the error do not crash maven this time. > The env command cannot run because maven cannot spawn other processes. I do > not know > how to modify this behaviour. > > > > > > > Brett Porter wrote: >> >> I believe someone encountered this recently and it was a result of >> running as the super user which had a very limited environment. You >> might find more information in the archives. >> >> Cheers, >> Brett >> >> 2008/9/29 greeklinux <[EMAIL PROTECTED]>: >>> >>> Hello, >>> >>> I am using maven, and I setup an CI system on a virtual server. >>> When the build process starts, maven fails with the >>> following error: >>> >>> Parsing POMs >>> ERROR: Failed to parse POMs >>> java.io.IOException: Cannot run program "env": java.io.IOException: >>> error=12, Cannot allocate memory >>>at java.lang.ProcessBuilder.start(ProcessBuilder.java:459) >>>at java.lang.Runtime.exec(Runtime.java:593) >>>at java.lang.Runtime.exec(Runtime.java:431) >>>at java.lang.Runtime.exec(Runtime.java:328) >>>at >>> org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:250) >>>at >>> org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:216) >>>at >>> org.apache.maven.project.interpolation.RegexBasedModelInterpolator.(RegexBasedModelInterpolator.java:63) >>>at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>> Method) >>>at >>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >>>at >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >>>at java.lang.reflect.Constructor.newInstance(Constructor.java:513) >>>at java.lang.Class.newInstance0(Class.java:355) >>>at java.lang.Class.newInstance(Class.java:308) >>>at >>> org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:44) >>>at >>> org.codehaus.plexus.DefaultPlexusContainer.createComponentInstance(DefaultPlexusContainer.java:1464) >>>at >>> org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:93) >>>at >>> org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) >>>at >>> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) >>>at >>> org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:129) >>>at >>> org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent(FieldComponentComposer.java:73) >>>at >>> org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:68) >>>at >>> org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexusContainer.java:1486) >>>at >>> org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:29) >>>at >>> org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) >>>at >>> org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) >>>at >>> org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) >>>at >>> org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) >>>at >>> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) >>>at org.codehaus.plexus.embed.Embedder.lookup(Embedder.java:78) >>>at hudson.maven.MavenEmbedder.start(MavenEmbedder.java:655) >>>at hudson.maven.MavenUtil.createEmbedder(MavenUtil.java:75) >>>at >>> hudson.tasks.Maven$MavenInstallation.createEmbedder(Maven.java:337) >>>at >>> hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:691) >>>at >>> hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:640) >>>at hudson.FilePath.act(FilePath.java:363) >>>at >>> hudson.maven.MavenModuleSetBuild$RunnerImpl.parsePoms(MavenModuleSetBuild.java:390) >>>at >>> hudson.maven
Maven @ ApacheCon US; Discounted rate until Fri Oct 3
For those thinking of attending ApacheCon US in New Orleans, these are the Maven sessions this year: * Brett Porter: Apache Maven, End-to-end (full-day training) http://us.apachecon.com/c/acus2008/sessions/89 * Brett Porter: More Apache Maven Best Practices (Presentation) http://us.apachecon.com/c/acus2008/sessions/50 * Carlos Sanchez: Q, Maven integration for Eclipse (Presentation) http://us.apachecon.com/c/acus2008/sessions/51 In addition to all the other useful Apache-related presentations, you'll no doubt find several Maven committers around the conference, Hackathon and Barcamp on Monday and Tuesday. For more information and registration, see http://www.us.apachecon.com/. There's still a discounted rate this week. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cannot run program "env"
Hello, thanks for the reply. I tried a 2.0.9 version and the 2.1 preview releases, but the error still show up. "Error getting environment vars for profile activation java.io.IOException: Cannot run program "env": java.io.IOException: error=12, Cannot allocate memory" I read in other posts, that there was a bug with the environment variables. But mine are fine. The good thing is the error do not crash maven this time. The env command cannot run because maven cannot spawn other processes. I do not know how to modify this behaviour. Brett Porter wrote: > > I believe someone encountered this recently and it was a result of > running as the super user which had a very limited environment. You > might find more information in the archives. > > Cheers, > Brett > > 2008/9/29 greeklinux <[EMAIL PROTECTED]>: >> >> Hello, >> >> I am using maven, and I setup an CI system on a virtual server. >> When the build process starts, maven fails with the >> following error: >> >> Parsing POMs >> ERROR: Failed to parse POMs >> java.io.IOException: Cannot run program "env": java.io.IOException: >> error=12, Cannot allocate memory >>at java.lang.ProcessBuilder.start(ProcessBuilder.java:459) >>at java.lang.Runtime.exec(Runtime.java:593) >>at java.lang.Runtime.exec(Runtime.java:431) >>at java.lang.Runtime.exec(Runtime.java:328) >>at >> org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:250) >>at >> org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:216) >>at >> org.apache.maven.project.interpolation.RegexBasedModelInterpolator.(RegexBasedModelInterpolator.java:63) >>at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >> Method) >>at >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >>at >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >>at java.lang.reflect.Constructor.newInstance(Constructor.java:513) >>at java.lang.Class.newInstance0(Class.java:355) >>at java.lang.Class.newInstance(Class.java:308) >>at >> org.codehaus.plexus.component.factory.java.JavaComponentFactory.newInstance(JavaComponentFactory.java:44) >>at >> org.codehaus.plexus.DefaultPlexusContainer.createComponentInstance(DefaultPlexusContainer.java:1464) >>at >> org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:93) >>at >> org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) >>at >> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) >>at >> org.codehaus.plexus.component.composition.FieldComponentComposer.assignRequirementToField(FieldComponentComposer.java:129) >>at >> org.codehaus.plexus.component.composition.FieldComponentComposer.assembleComponent(FieldComponentComposer.java:73) >>at >> org.codehaus.plexus.component.composition.DefaultComponentComposerManager.assembleComponent(DefaultComponentComposerManager.java:68) >>at >> org.codehaus.plexus.DefaultPlexusContainer.composeComponent(DefaultPlexusContainer.java:1486) >>at >> org.codehaus.plexus.personality.plexus.lifecycle.phase.CompositionPhase.execute(CompositionPhase.java:29) >>at >> org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) >>at >> org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) >>at >> org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) >>at >> org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:92) >>at >> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) >>at org.codehaus.plexus.embed.Embedder.lookup(Embedder.java:78) >>at hudson.maven.MavenEmbedder.start(MavenEmbedder.java:655) >>at hudson.maven.MavenUtil.createEmbedder(MavenUtil.java:75) >>at >> hudson.tasks.Maven$MavenInstallation.createEmbedder(Maven.java:337) >>at >> hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:691) >>at >> hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:640) >>at hudson.FilePath.act(FilePath.java:363) >>at >> hudson.maven.MavenModuleSetBuild$RunnerImpl.parsePoms(MavenModuleSetBuild.java:390) >>at >> hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:285) >>at >> hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:240) >>at hudson.model.Run.run(Run.java:793) >>at >> hudson.m
RE: mirrors, oh mirrors
szczepiq wrote: > Hi all, > > Mirrors are giving me headache recently. See this: > > > > corporate-repo > corporate-repo-backup > ... > * > > > corporate-repo-backup > corporate-repo-backup > ... > * > > > > Above configuration is a dead simple fail-over system. If > corporate-repo is down, I want the corporate-repo-backup to mirror > everything. Unfortunately it doesn't work :( It seems only last mirror > is active when "mirrorOf" property is the same. Is this how it suppose > to work? After all, the point of mirrors is to provide multiple > locations for the same content, isn't it? Any input? The point of mirrors is to provide an alternate location for the content. This does not imply fallback. You can use for quite some OS organizations mirrors of their content (Apache, SF,net, ...), however, if you select a mirror and it is not available or out of date and your file is not found, you're also not automagically redirected to a different one, that is available and in sync. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mirrors, oh mirrors
Hi all, Mirrors are giving me headache recently. See this: corporate-repo corporate-repo-backup ... * corporate-repo-backup corporate-repo-backup ... * Above configuration is a dead simple fail-over system. If corporate-repo is down, I want the corporate-repo-backup to mirror everything. Unfortunately it doesn't work :( It seems only last mirror is active when "mirrorOf" property is the same. Is this how it suppose to work? After all, the point of mirrors is to provide multiple locations for the same content, isn't it? Any input? Cheers, Szczepan Faber - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Cobertura plugin doesn't generate XML
Answering the questions of Jens (later post) and yourself: 1. I had the plugin in the reporting section. If I put it into the build section, Maven tells me that the plugin can't be downloaded (we use an internal Archiva server, which should load unknown stuff from the official Maven repos). 2. Version 2.2 Best regards, Eric > -Ursprüngliche Nachricht- > Von: Nick Stolwijk [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 29. September 2008 12:33 > An: Maven Users List > Betreff: Re: Cobertura plugin doesn't generate XML > > I can think of two things, that could go wrong: > > 1. Did you configure this under the reporting section or under the > build section of your pom file? It should be under the build section > afaik. > > 2. Otherwise, what version of the cobertura plugin are you using? > > Hth, > > Nick Stolwijk > ~Java Developer~ > > Iprofs BV. > Claus Sluterweg 125 > 2012 WS Haarlem > www.iprofs.nl > > > > On Mon, Sep 29, 2008 at 12:04 PM, Lewis, Eric > <[EMAIL PROTECTED]> wrote: > > Hi > > > > I'm trying to generate an XML report using the Cobertura plugin (2.2 > > apparently). I configured the plugin according to the documentation: > > > > > > org.apache.maven.plugins > > cobertura-maven-plugin > > > > > > xml > > > > > > > > > > Then I start Maven (mvn clean install cobertura:cobertura), but the > > plugin generates the HTML reports under .../target/site/cobertura/ > > (which I tell it not to do), but doesn't create any XML files. > > > > What am I doing wrong? > > > > Best regards, > > Eric > > > > > - > > 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]
Travel Assistance to ApacheCon US 2008 - 3 days to apply!
The Travel Assistance Committee is taking in applications for those wanting to attend ApacheCon US 2008 between the 3rd and 7th November 2008 in New Orleans. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon US 2008 who need some financial support in order to get there. There are VERY few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF and open source in general. Financial assistance is available for flights, accommodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in Europe and or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon US of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the application form and details for submitting. Time is very tight for this event, so applications are open now and will end on the 2nd October 2008 - to give enough time for travel arrangements to be made. Good luck to all those that will apply. Regards, The Travel Assistance Committee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Cobertura plugin doesn't generate XML
Hello, may you can try the configuration in your reporting section of the POM. - jens >Hi >I'm trying to generate an XML report using the Cobertura plugin (2.2 >apparently). I configured the plugin according to the documentation: > > org.apache.maven.plugins > cobertura-maven-plugin > > > xml > < > >Then I start Maven (mvn clean install cobertura:cobertura), but the >plugin generates the HTML reports under .../target/site/cobertura/ >(which I tell it not to do), but doesn't create any XML files. >What am I doing wrong? >Best regards, >Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cobertura plugin doesn't generate XML
I can think of two things, that could go wrong: 1. Did you configure this under the reporting section or under the build section of your pom file? It should be under the build section afaik. 2. Otherwise, what version of the cobertura plugin are you using? Hth, Nick Stolwijk ~Java Developer~ Iprofs BV. Claus Sluterweg 125 2012 WS Haarlem www.iprofs.nl On Mon, Sep 29, 2008 at 12:04 PM, Lewis, Eric <[EMAIL PROTECTED]> wrote: > Hi > > I'm trying to generate an XML report using the Cobertura plugin (2.2 > apparently). I configured the plugin according to the documentation: > > > org.apache.maven.plugins > cobertura-maven-plugin > > > xml > > > > > Then I start Maven (mvn clean install cobertura:cobertura), but the > plugin generates the HTML reports under .../target/site/cobertura/ > (which I tell it not to do), but doesn't create any XML files. > > What am I doing wrong? > > Best regards, > Eric > > - > 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]
Cobertura plugin doesn't generate XML
Hi I'm trying to generate an XML report using the Cobertura plugin (2.2 apparently). I configured the plugin according to the documentation: org.apache.maven.plugins cobertura-maven-plugin xml Then I start Maven (mvn clean install cobertura:cobertura), but the plugin generates the HTML reports under .../target/site/cobertura/ (which I tell it not to do), but doesn't create any XML files. What am I doing wrong? Best regards, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi module Setup / release:prepare
Hi Karl Heinz! On 29 Sep 2008, Karl Heinz Marbaise wrote: > i have a little problem with the release:prepare running in Maven. > > I have a mutli module setup which seemed to be ok > > parent > +--- Module A (depends on C) (result in tar.gz) > +--- Module B > +--- Module C > +--- Module WAR > +--- Module D (Tomcat with .war from Module WAR as a .tar.gz) > +--- Module E (only multiple tar.gz with config files; no java code) > +--- Module project (which comprise of the above as .tar.gz) > > after running mvn release:prepare i allway get an "Failed to resolve > artifact." message... In which module do you get the error message? > What i have observed is, if i delete the contents of my local repository > and try to do an mvn package this will fail the first time > If i do a mvn install before everything is fine We are having the same problem here with EARs and skinny WARs. It's been a while since I last looked what the problem is but our problem is definitely related to the skinny WAR problem [0] and your's might be too. The workaround we are using is to run "mvn install" whenever such a problem occurs. > I'm not sure but it seemed to me there is something wrong in my > dependencies...but i'm not sure where to search for Try running mvn -X to see where your dependencies come from. Search the output for "selected for runtime" and "from the repository". This might lead you on the right track. hth, - martin [0] http://docs.codehaus.org/display/MAVENUSER/Solving+the+Skinny+Wars+problem signature.asc Description: PGP signature
Multi module Setup / release:prepare
Hi there, i have a little problem with the release:prepare running in Maven. I have a mutli module setup which seemed to be ok parent +--- Module A (depends on C) (result in tar.gz) +--- Module B +--- Module C +--- Module WAR +--- Module D (Tomcat with .war from Module WAR as a .tar.gz) +--- Module E (only multiple tar.gz with config files; no java code) +--- Module project (which comprise of the above as .tar.gz) after running mvn release:prepare i allway get an "Failed to resolve artifact." message... What i have observed is, if i delete the contents of my local repository and try to do an mvn package this will fail the first time If i do a mvn install before everything is fine I'm not sure but it seemed to me there is something wrong in my dependencies...but i'm not sure where to search for Does some has a hint ? Thanks in advance.. Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
reactor plugin "Embedded error: Roots differ"
Hi, I'm trying to get the reactor plugin to work for our project structure (simplified version): project-root/ /modules pom.xml /A /api /impl /B /api /impl /root-pom/pom.xml The root-pom/pom.xml contains a modules section that just references the project modules ../modules Now, from the root-pom directory I do "mvn reactor-make -Dmake.artifacts=A-api" which should normally trigger B-api,A-api to be built. Instead i get [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Problem generating dependency tree Embedded error: Roots differ [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Problem generating dependency tree at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:701) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:551) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:521) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:369) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:266) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:302) 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.MojoExecutionException: Problem generating dependency tree at org.apache.maven.plugin.reactor.MakeMojo.execute(MakeMojo.java:168) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:458) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:676) ... 16 more Caused by: org.apache.maven.plugin.reactor.RelativePather$DifferentRootsException: Roots differ at org.apache.maven.plugin.reactor.RelativePather.getRelativePath(RelativePather.java:41) at org.apache.maven.plugin.reactor.MakeMojo.execute(MakeMojo.java:159) ... 18 more [INFO] Any ideas ? Jorg
repository for youtube api
Hi, I need to use youtube api in my 'mavenized' app, is there a youtube dependency somewhere? thanks. A.C. -- View this message in context: http://www.nabble.com/repository-for-youtube-api-tp19719346p19719346.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven schemaspy plugin with MSSql
Hi all, Has anyone used before maven schemaspy plugin to generate DB schema site from MSSql? I'm trying to configure schemaspy plugin as described in http://maven.wakaleo.com/mojo/maven-schemaspy-plugin/usage.html http://maven.wakaleo.com/mojo/maven-schemaspy-plugin/usage.html as folows com.wakaleo.schemaspy maven-schemaspy-plugin 1.0 mssql [DbName] [Host] [Login] [Password] . But during build of my site I'm getting this error Parameter '-port' (database port on host) missing. It is required for the specified database type. Why maven schemaspy plugin didn't trying to connect to MSSql with defaul port? Or how can I pass port to maven schemaspy plugin? Plz help, Thanks -- View this message in context: http://www.nabble.com/Maven-schemaspy-plugin-with-MSSql-tp19719190p19719190.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: maven archetype
Thx you, or is there a possibility by using this command to integrate source/projects report information? Mvn archetype:create -DarchetpeGroupId=org.apache.maven.archetypes \ -DarchetypeArtifactId=maven-archetype-site \ -DgroupId=com.mycompany \ -DartifactId=my-site It creates a dedicated site project where I can customize the layout and the html output stuff. How can I integrate my java sources and reports (e.g. from checkstyle, pmd, xref...) to this site? Regards, Matthias -Ursprüngliche Nachricht- Von: Thor [mailto:[EMAIL PROTECTED] Gesendet: Montag, 29. September 2008 03:46 An: Maven Users List; [EMAIL PROTECTED] Betreff: Re: maven archetype The only thing I can come up with it's to add each file as a resource on the archetpe.xml of your archetype (wich is a real pain). Or you could try the mvn archetype:create-from-project, it'll generate an archetype from your current project (though, I haven't used it for that kind configuration) hope it helps... My regards... On Sun, Sep 28, 2008 at 2:07 PM, Matthias Dorfner <[EMAIL PROTECTED]>wrote: > Sorry for that maybe stupid question, but I didn't find an answer > consulting the maven website and google. > > > > I created an archetype quickstart skeleton, as well as a dedicated site > skeleton with the archetype plugin (with the goals create and generate). > > What I'm looking for is a skeleton that combines both. So I can put my > already existing java files in the src/java folder, configure my site > templates, apt, faq files etc. within the src/site folder and use the site > plugin to generate a customized project page with javadoc, project reports > information… for my source code. > > > > How can I set this up easily? > > > > Thanks in advance! > > > > Regards, > > Matthias > > > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
