Re: JAVADOC-plugin: include comments from local dependent projects
Unfortunately it does not. The problem is that
excludes packages from being processed at all, and I only need to exclude
packages from javaDoc, not from source code analyzis (and thus, comment
inheritance).
i think right now I'll settle with ant script which is working. Thanks
everyone for the answers
2010/2/2 Jeff Jensen
> Possibly what you are looking for is not a Maven related thing at all but
> how Javadoc works. If you add
> /**
> * {...@inheritdoc}
> */
> above the methods in the implementation classes that implement the
> interface methods, Javadoc copies it from the interface to the implementing
> class' generated HTML files.
>
> Additionally, if using Java 5 or newer, the @Override annotation does the
> same thing (and is the preferred approach - no need to do both).
>
> Then, the packaged Javadoc will have what I think you want.
>
>
> -Original Message-
> From: Wayne Fay [mailto:wayne...@gmail.com]
> Sent: Monday, February 01, 2010 4:48 PM
> To: Maven Users List
> Subject: Re: JAVADOC-plugin: include comments from local dependent projects
>
> > project (B). E.g. A contains interfaces, and B implementations. The
> question
> > is: how can I build docs for B so that, if none specified, method
> > descriptions are inherited from A?
>
> There's a good chance your specific usage of the Javadoc plugin is not
> currently supported. I've certainly never needed nor wanted to do what
> you're doing.
>
> Look at the source code for the m-javadoc-p and see if you can figure
> out a way to patch it to support your requirement, or file a Jira and
> wait for someone else to code it for you.
>
> Wayne
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
--
Andrey
Re: JAVADOC-plugin: include comments from local dependent projects
Sorry, but I don't understand. I already have small library (A) and main project (B). E.g. A contains interfaces, and B implementations. The question is: how can I build docs for B so that, if none specified, method descriptions are inherited from A? 2010/2/1 Ron Wheeler > Andrey Razumovsky wrote: > >> Hello, >> >> Imagine I have two projects, A and B. Both are mine projects and aren't >> published anywhere on the internet (don't have url). A is referenced from >> B. >> Classes from B inherit a lot from classes from A. >> The goal is to build docs for B, and include there only B sources. But >> also >> I want comments for B methods to be automatically inherited from A docs. >> Currently I've been unable to do that. >> When I specify to local storage of A docs, links are created, but >> docs are not inherited. >> When I specify to storage of A src, docs are inherited, but >> classes from A are included in docs as well (unwanted). Trying to exclude >> them with results in losing docs inheritance. >> >> BTW I used to solve the problem with Ant once: >> > packagenames="B.PACKAGE.*" /> >> >> How can I do that with Maven? >> >> Thanks in advance, >> Andrey >> >> >> > Are you sure that you would not be happier with more small library projects > that create JARs dependencies for the main projects? > Combined with interfaces and implementations, you should get a decent set > of docs plus a set of code that is easier to maintain. > > Ron > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Andrey
Re: Automatic updates from repository
Hi, Thanks for an answer. I don't want to use snapshot for every pom because it brings ugly postfixes for artifacts e.g. when I deploy them to server, and i don't want to configure new names for every artifact in my POM's deploy to server executions. Removing artifact from local repo isn't fine because I want automatic updates for all developers 2010/2/1 Ilya Kazakevich > Hello, > > Why do not you want to use SNAPSHOT? > > Fixed version should never be changed but snapshot can. > You have SNAPSHOT while you develop your artifact, and when you're ready to > release it -- you give it version number. > > Other artifacts may depend on your snapshot. If so -- maven knows that > snapshot could be changed and fetches new version of snapshot periodically. > But if you depend on fixed version (i.e: my-artifact-1.2.3) and you already > have it in your local repository -- maven would not fetch it again, because > it should be the same and maven knows it. > > If you really want to refetch such artifact -- simply remove it from your > local repository, but that's bad idea because it breakes maven's philosophy > and brings pain in your development process. > > Ilya. > > > -Original Message- > From: Andrey Razumovsky [mailto:razumovsky.and...@gmail.com] > Sent: Monday, February 01, 2010 1:42 PM > To: Maven Users List > Subject: Automatic updates from repository > > Hello, > > In our company we've got a local repository. There's an artifact (packaged > as POM or as JAR), which is deployed by me and used by other projects. It > is > changing frequently, so we don't want referencing POM to change often (i.e. > version changes rarely). Now it seems new versions are not downloaded by > referencing projects automatically at build time. Is it because I haven't > specified "SNAPSHOT" postfix? If yes, is there a way to allow automatic > changes detection without "SNAPSHOT" postfix? > > Thanks, > Andrey > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Andrey
Automatic updates from repository
Hello, In our company we've got a local repository. There's an artifact (packaged as POM or as JAR), which is deployed by me and used by other projects. It is changing frequently, so we don't want referencing POM to change often (i.e. version changes rarely). Now it seems new versions are not downloaded by referencing projects automatically at build time. Is it because I haven't specified "SNAPSHOT" postfix? If yes, is there a way to allow automatic changes detection without "SNAPSHOT" postfix? Thanks, Andrey
JAVADOC-plugin: include comments from local dependent projects
Hello, Imagine I have two projects, A and B. Both are mine projects and aren't published anywhere on the internet (don't have url). A is referenced from B. Classes from B inherit a lot from classes from A. The goal is to build docs for B, and include there only B sources. But also I want comments for B methods to be automatically inherited from A docs. Currently I've been unable to do that. When I specify to local storage of A docs, links are created, but docs are not inherited. When I specify to storage of A src, docs are inherited, but classes from A are included in docs as well (unwanted). Trying to exclude them with results in losing docs inheritance. BTW I used to solve the problem with Ant once: How can I do that with Maven? Thanks in advance, Andrey
Problems with javadoc plugin
Hello,
We're having problems with javadoc plugin. It all started when we tried to
set up a new Hudson build configuration for JDK1.6. Now configuration's name
contained "(" symbol and maven-javadoc-plugin-2.5 stopped to work. Example
of error at [1].
Then we switched to version 2.6. It helped! But now all builds were
*extremely* slow. At the slowest time console showed lines like this;
[INFO] The goal
'org.apache.maven.plugins:maven-javadoc-plugin:2.6:javadoc' has not be
previously called for the project:
'org.apache.cayenne.itests:pojo:jar:3.1-SNAPSHOT'. Trying to invoke
it...
The strange thing is that this operation is noop, there aren't any javadocs
to generate (or there are few)! So some analizys takes a lot of time (more
than 10 minutes for our project). At [2] there's a console log for this case
(sorry, it's big!)
then we switched to 2.6.1 hoping the problem was fixed there. Alas, it is
same slow and broke our builds absolutely. Don't know the reason, the log is
at [3].
So our questions are:
1. Why javadoc generation became so slow in 2.6?
2. What's the reason of regression in 2.6.1?
[1].
http://hudson.zones.apache.org/hudson/job/Cayenne-trunk/5/jdk=JDK%201.6%20%28latest%29/console
[2].
http://hudson.zones.apache.org/hudson/job/Cayenne-trunk/jdk=JDK%201.6%20%28latest%29/24/consoleFull
[3].
http://hudson.zones.apache.org/hudson/job/Cayenne-trunk/22/jdk=JDK%201.6%20%28latest%29/console
Thanks in advance,
Andrey
Re: Surefire 2.5 release
Oh, and the link. You can vote here: http://jira.codehaus.org/browse/SUREFIRE-578 2009/10/12 Andrey Razumovsky > Created a JIRA. > Actually, since Surefire has only "test" dependency, so it will not be > anyhow included in a release, so no problems should occur > > > 2009/10/12 Dan Tran > >> yes, I did cut a sureplugin release my self at work, however since you >> are an apache project, dont think you can release Cayenne with a >> private copy of surefire. >> >> Perhaps you can file a JIRA to release 2.5, i am sure lots of folks >> will vote for it, that will get attention. >> >> -Dan >> >> On Sun, Oct 11, 2009 at 10:01 PM, Andrey Razumovsky >> wrote: >> > Well, we can if we want to - we have a repository which can be used for >> such >> > artifacts. So you advice to make a *local* copy of 2.5-SNAPSHOT and use >> it >> > until official 2.5 is released? >> > >> > Thanks, >> > >> > 2009/10/12 Dan Tran >> > >> >> since Apache Cayenne cant just fork its own copy of surefire plugin, i >> >> think releasing 2.5 is badly needed. >> >> >> >> -D >> >> >> >> On Sun, Oct 11, 2009 at 4:26 PM, Barrie Treloar >> >> wrote: >> >> > On Mon, Oct 12, 2009 at 5:48 AM, Andrey Razumovsky >> >> > wrote: >> >> >> Hello, >> >> >> >> >> >> While enchancing our Hudson builds here at Apache Cayenne, we got >> bitten >> >> by >> >> >> SUREFIRE-551. It is now fixed, but doesn't exist in any released >> >> version. >> >> >> We've found the snapshot in http://repository.apache.org/snapshots/. >> So >> >> our >> >> >> questions are: >> >> >> 1. Is 2.5-SNAPSHOT stable enough? >> >> >> 2. Can we rely on http://repository.apache.org/snapshots/repository in >> >> our >> >> >> builds (i.e. aren't there any plans to delete snapshot from that >> repo)? >> >> >> 3. When official 2.5 will be released? >> >> >> >> >> >> Thanks, >> >> >> Andrey >> >> >> >> >> > >> >> > For 1) & 2) NEVER rely on snapshots for your builds. >> >> > >> >> > There are a number of problems with using the snapshot repository. >> >> > 1) You can't select which snapshots to use, it is all or nothing. So >> >> > if you aren't following best practice and locking down plugin >> versions >> >> > then you will automatically start using snapshot versions when you >> >> > didnt want to. >> >> > 2) Snapshots get rebuilt so it may work one day and fail the next. >> >> > >> >> > I wrote up the steps I use for this scenario >> >> > http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins >> >> > >> >> > Essentially you take a copy of the source and build a local version >> of >> >> > the plugin. >> >> > If you use a suitable numbering scheme when the official release >> >> > arrives it will replace your patched version. >> >> > >> >> > I can't answer 3) for you. >> >> > >> >> > - >> >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> >> > For additional commands, e-mail: users-h...@maven.apache.org >> >> > >> >> > >> >> >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> >> For additional commands, e-mail: users-h...@maven.apache.org >> >> >> >> >> > >> > >> > -- >> > Andrey >> > >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > > -- > Andrey > -- Andrey
Re: Surefire 2.5 release
Created a JIRA. Actually, since Surefire has only "test" dependency, so it will not be anyhow included in a release, so no problems should occur 2009/10/12 Dan Tran > yes, I did cut a sureplugin release my self at work, however since you > are an apache project, dont think you can release Cayenne with a > private copy of surefire. > > Perhaps you can file a JIRA to release 2.5, i am sure lots of folks > will vote for it, that will get attention. > > -Dan > > On Sun, Oct 11, 2009 at 10:01 PM, Andrey Razumovsky > wrote: > > Well, we can if we want to - we have a repository which can be used for > such > > artifacts. So you advice to make a *local* copy of 2.5-SNAPSHOT and use > it > > until official 2.5 is released? > > > > Thanks, > > > > 2009/10/12 Dan Tran > > > >> since Apache Cayenne cant just fork its own copy of surefire plugin, i > >> think releasing 2.5 is badly needed. > >> > >> -D > >> > >> On Sun, Oct 11, 2009 at 4:26 PM, Barrie Treloar > >> wrote: > >> > On Mon, Oct 12, 2009 at 5:48 AM, Andrey Razumovsky > >> > wrote: > >> >> Hello, > >> >> > >> >> While enchancing our Hudson builds here at Apache Cayenne, we got > bitten > >> by > >> >> SUREFIRE-551. It is now fixed, but doesn't exist in any released > >> version. > >> >> We've found the snapshot in http://repository.apache.org/snapshots/. > So > >> our > >> >> questions are: > >> >> 1. Is 2.5-SNAPSHOT stable enough? > >> >> 2. Can we rely on http://repository.apache.org/snapshots/ repository > in > >> our > >> >> builds (i.e. aren't there any plans to delete snapshot from that > repo)? > >> >> 3. When official 2.5 will be released? > >> >> > >> >> Thanks, > >> >> Andrey > >> >> > >> > > >> > For 1) & 2) NEVER rely on snapshots for your builds. > >> > > >> > There are a number of problems with using the snapshot repository. > >> > 1) You can't select which snapshots to use, it is all or nothing. So > >> > if you aren't following best practice and locking down plugin versions > >> > then you will automatically start using snapshot versions when you > >> > didnt want to. > >> > 2) Snapshots get rebuilt so it may work one day and fail the next. > >> > > >> > I wrote up the steps I use for this scenario > >> > http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins > >> > > >> > Essentially you take a copy of the source and build a local version of > >> > the plugin. > >> > If you use a suitable numbering scheme when the official release > >> > arrives it will replace your patched version. > >> > > >> > I can't answer 3) for you. > >> > > >> > - > >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> > For additional commands, e-mail: users-h...@maven.apache.org > >> > > >> > > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > > > -- > > Andrey > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Andrey
Re: Surefire 2.5 release
Well, we can if we want to - we have a repository which can be used for such artifacts. So you advice to make a *local* copy of 2.5-SNAPSHOT and use it until official 2.5 is released? Thanks, 2009/10/12 Dan Tran > since Apache Cayenne cant just fork its own copy of surefire plugin, i > think releasing 2.5 is badly needed. > > -D > > On Sun, Oct 11, 2009 at 4:26 PM, Barrie Treloar > wrote: > > On Mon, Oct 12, 2009 at 5:48 AM, Andrey Razumovsky > > wrote: > >> Hello, > >> > >> While enchancing our Hudson builds here at Apache Cayenne, we got bitten > by > >> SUREFIRE-551. It is now fixed, but doesn't exist in any released > version. > >> We've found the snapshot in http://repository.apache.org/snapshots/. So > our > >> questions are: > >> 1. Is 2.5-SNAPSHOT stable enough? > >> 2. Can we rely on http://repository.apache.org/snapshots/ repository in > our > >> builds (i.e. aren't there any plans to delete snapshot from that repo)? > >> 3. When official 2.5 will be released? > >> > >> Thanks, > >> Andrey > >> > > > > For 1) & 2) NEVER rely on snapshots for your builds. > > > > There are a number of problems with using the snapshot repository. > > 1) You can't select which snapshots to use, it is all or nothing. So > > if you aren't following best practice and locking down plugin versions > > then you will automatically start using snapshot versions when you > > didnt want to. > > 2) Snapshots get rebuilt so it may work one day and fail the next. > > > > I wrote up the steps I use for this scenario > > http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins > > > > Essentially you take a copy of the source and build a local version of > > the plugin. > > If you use a suitable numbering scheme when the official release > > arrives it will replace your patched version. > > > > I can't answer 3) for you. > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Andrey
Surefire 2.5 release
Hello, While enchancing our Hudson builds here at Apache Cayenne, we got bitten by SUREFIRE-551. It is now fixed, but doesn't exist in any released version. We've found the snapshot in http://repository.apache.org/snapshots/. So our questions are: 1. Is 2.5-SNAPSHOT stable enough? 2. Can we rely on http://repository.apache.org/snapshots/ repository in our builds (i.e. aren't there any plans to delete snapshot from that repo)? 3. When official 2.5 will be released? Thanks, Andrey
How to setup includes for jar plugin using one plain property?
Hi,
I need to setup includes for jar using just one property, not the
complicated ... structure, just the way it can be done
for war plugin. So
1. I've found "maven.jar.includes" property, but I've been unable to set it
for plugin execution. How can I do that?
2. Is it possible to setup a variable with XML tree? Then I would put
something like ${jarIncludes} to my plugin execution
configuration
Thanks,
--
Andrey
Re: Maven compiler plugin adds unnecessary dependent classes to output folder
BWT, is it possible to include *only* classes I specify in tag and dependent from my classpath? E.g. my structure is mypackage client A.java B.java server C.java --> C extends A and maven-compiler-plugin contains mypackage/server/** then I want my resulting jar contain only C and A classes. I thought normal javac does just that - compliles specified classes and dependent ones, but Maven gives me compiler error telling that client classes were not found.. 2009/8/31 Andrey Razumovsky > Thanks for your answers. > Stephen, you are right. javax.servlet is coming from GWT-dev jar, and > others from my GWT-based libraries, which must contain sources. How can I > exclude them from compilation? Adding > > > > org.apache.maven.plugins > maven-compiler-plugin > > > mypackage/** > > > > > didn't help... > > 2009/8/31 Stephen Connolly > > is this not the bug where if the dependent jar contains .java files, then >> javac decides to compile them? >> >> check the jar that you think the classes are coming from and see if that >> jar also has the source of the classes within >> >> Sent from my [rhymes with myPod] ;-) >> >> >> On 30 Aug 2009, at 22:06, Wendy Smoak wrote: >> >> On Sun, Aug 30, 2009 at 1:15 PM, Andrey >>> Razumovsky wrote: >>> >>> I've got a project with e.g. jar packaging. All my dependencies have >>>> "provided" scope. My problem is that Maven compiler plugin adds >>>> unnecessary >>>> classes from dependent library to output folder - e.g. if I have a class >>>> mypack.MyServlet extends HttpServlet, javax.servlet package will be >>>> present >>>> in compile output directory and therefore will be added to resulting >>>> JAR. >>>> >>> >>> Can you reproduce this with a simple project started from the >>> quickstart archetype? I've never seen the jar plugin package up >>> dependencies. (You can do it with the assembly plugin.) Without >>> seeing the pom it's hard to guess what you've done so far. >>> >>> -- >>> Wendy >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> >
Re: Maven compiler plugin adds unnecessary dependent classes to output folder
Thanks for your answers. Stephen, you are right. javax.servlet is coming from GWT-dev jar, and others from my GWT-based libraries, which must contain sources. How can I exclude them from compilation? Adding org.apache.maven.plugins maven-compiler-plugin mypackage/** didn't help... 2009/8/31 Stephen Connolly > is this not the bug where if the dependent jar contains .java files, then > javac decides to compile them? > > check the jar that you think the classes are coming from and see if that > jar also has the source of the classes within > > Sent from my [rhymes with myPod] ;-) > > > On 30 Aug 2009, at 22:06, Wendy Smoak wrote: > > On Sun, Aug 30, 2009 at 1:15 PM, Andrey >> Razumovsky wrote: >> >> I've got a project with e.g. jar packaging. All my dependencies have >>> "provided" scope. My problem is that Maven compiler plugin adds >>> unnecessary >>> classes from dependent library to output folder - e.g. if I have a class >>> mypack.MyServlet extends HttpServlet, javax.servlet package will be >>> present >>> in compile output directory and therefore will be added to resulting JAR. >>> >> >> Can you reproduce this with a simple project started from the >> quickstart archetype? I've never seen the jar plugin package up >> dependencies. (You can do it with the assembly plugin.) Without >> seeing the pom it's hard to guess what you've done so far. >> >> -- >> Wendy >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Maven compiler plugin adds unnecessary dependent classes to output folder
Hi Maven guru, I've got a project with e.g. jar packaging. All my dependencies have "provided" scope. My problem is that Maven compiler plugin adds unnecessary classes from dependent library to output folder - e.g. if I have a class mypack.MyServlet extends HttpServlet, javax.servlet package will be present in compile output directory and therefore will be added to resulting JAR. This is undesirable, of course. Strange, I have such problems with only several dependent artifacts (in fact, javax.servlet:servlet-api and my own artifacts). What could cause that? I've already disabled all plugins, but jar keeps to be created too fat. I'm using Maven 2.2.0 Thanks in advance, Andrey
