extra jars not kept up-to-date in remote repository
Hi- We're building with Continuum and I have the problem that builds aren't causing all of the artifacts to be stored. What seems to happen is that for the first build for a given date code, all the source, test, and javadoc jars get deployed. For subsequent builds that have the same date in the name, only the primary library jar gets stores (see example at end). If the date code is bumped, then the cycle starts over--all the artifacts are stored one time but sub- sequent builds do not cause them to be stored. These are snapshots, BTW. The main problem this causes is on the developer side. When one does something like: mvn -U eclipse:eclipse sources do not get attached. I have all the requisite plugins for source, javadoc, and test jar creation in the poms. Any ideas? TIA, -dub example: Index of /.../service-domain/1.0-SNAPSHOT ... service-domain-1.0-20061213.005715-4-javadoc.jar 12-Dec-2006 19:59 174K service-domain-1.0-20061213.005715-4-javadoc.jar.md5 12-Dec-2006 20:00 32 service-domain-1.0-20061213.005715-4-javadoc.jar.sha1 12-Dec-2006 20:00 40 service-domain-1.0-20061213.005715-4-sources.jar 12-Dec-2006 19:59 15K service-domain-1.0-20061213.005715-4-sources.jar.md5 12-Dec-2006 19:59 32 service-domain-1.0-20061213.005715-4-sources.jar.sha1 12-Dec-2006 19:59 40 service-domain-1.0-20061213.005715-4-tests.jar12-Dec-2006 19:59 6.9K service-domain-1.0-20061213.005715-4-tests.jar.md512-Dec-2006 19:59 32 service-domain-1.0-20061213.005715-4-tests.jar.sha1 12-Dec-2006 19:59 40 service-domain-1.0-20061213.005715-4.jar 12-Dec-2006 19:59 19K service-domain-1.0-20061213.005715-4.jar.md5 12-Dec-2006 19:59 32 service-domain-1.0-20061213.005715-4.jar.sha1 12-Dec-2006 19:59 40 service-domain-1.0-20061213.005715-4.pom 12-Dec-2006 19:59 469 service-domain-1.0-20061213.005715-4.pom.md5 12-Dec-2006 19:59 32 service-domain-1.0-20061213.005715-4.pom.sha1 12-Dec-2006 19:59 40 service-domain-1.0-20061213.222334-5.jar 13-Dec-2006 17:40 19K service-domain-1.0-20061213.222334-5.jar.md5 13-Dec-2006 17:40 32 service-domain-1.0-20061213.222334-5.jar.sha1 13-Dec-2006 17:40 40 service-domain-1.0-20061213.222334-5.pom 13-Dec-2006 17:40 686 service-domain-1.0-20061213.222334-5.pom.md5 13-Dec-2006 17:40 32 service-domain-1.0-20061213.222334-5.pom.sha1 13-Dec-2006 17:40 40 ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
successful AJDT integration?
Good morning-
I'm trying to figure out the best way to
use AspectJ with both Eclipse and Maven 2.
Problem 1:
I have the Codehaus plugin installed and
working. But the eclipse:eclipse target
does not configure the project as AspectJ.
Does anyone know if this feature is being
considered? If it is not in the works
already, in which plugin (aspectj or
eclipse or both) should the support lie?
Problem 2:
Say the rt dependency in Maven is set
to Eclipse 1.5.2a. Run eclipse:eclipse
target and the dependency is is set
correctly in the IDE. However, changing
the project to an AJ project from within
the IDE (required because of P1 above),
adds a conflicting dependency on a jar from
AJDT itself (1.5.2.something).
Problem 3:
There is, AFAICT, no Maven source location
convention for source files that require an
AspectJ compiler. I am not sure that
src/{main,test}/java is the correct
place since it is not strictly Java code.
I imagine that there are good reasons
against establishing a convention such as
using src/{main,test}/aspectj and I'd like
to hear them. Pragmatically wrt to
the topic at hand, the use of the
AspectJ compiler is all-or-nothing at the
project level in Eclipse so a separate
code location is meaningless there. But, I
don't think basic build convention
decisions should be made on the basis
of supporting any particular development
tool.
I know this is a big conceptual
problem. The value of AspectJ in many
cases is to enable unanticipated extension
of Java software. So, a large portion
of the code that is compiled/woven by ajc is
not aware (nor should it be) that it is
being advised--meaning the advised code
developer would rightly place sources in
.../java. Aspects might be best packaged
separately for such situations. But, a
growing body of software is being designed
with aspects for application logic. That
means, for instance, pointcuts in class
definitions and aspect source files mixed
in with standard java sources. Such code
might belong in a directory such as
.../aspectj to signal, by convention, that
the code requires an AspectJ compiler.
There are many such issues with this
particular language because it doesn't fit
traditional language models and probably
breaks subtle assumptions in the models
of many development tools such as Maven
and Eclipse.
Any thoughts? Am I missing some
fundamental piece of understanding that
makes AJDT and Maven integration a
snap?
TIA,
-dub
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: creating and using source archive
Jamie Bisotti wrote: On 4/26/06, Aaron Freeman <[EMAIL PROTECTED]> wrote: So what you all are saying is that the "eclipse:eclipse -DdownloadSources=true" command is the only way to get Maven to copy source jars into the local repository. So if you already have .project and .classpath file, the there is no way to get the sources in the local repository without messing up my .project and .classpath file. I think that is correct. In browsing mail archives and Jira reports, I get the impression that the eclipse plugin is the reason that source archives exist in the repositories at all. Of course, now that sources might start to show up in the repositories, it opens up all kinds of interesting possibilities. For instance, the facility could be used to create a complete javadoc site for a project and all of its dependencies with near-zero configuration. Similarly, for jobs that require available 3rd-party source code be delivered with the system, having those sources--tied to exact releases--available in a repo could help ease the pain of "operation shrinkwrap" (as a colleague used to call it). -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: creating and using source archive
Tom Huybrechts wrote: > The Eclipse plugin will (or should) > only download javadocs if the > sources are not available. Makes > sense for Eclipse, since it will > extract the javadocs from the sources if needed. Ah. I see. I deleted a source archive and it did indeed attach the javadoc archive instead. However, I think it should attach both if if finds them. In Eclipse, shift-f2 pops up a browser pointed at the javadocs for the item under the cursor. If only the sources are attached that function doesn't work. With only the sources attached, hovering over an item shows the javadoc in a local window but the ui is not as functional as the normal browser- based api docs. -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: creating and using source archive
Tom Huybrechts wrote: If you execute 'mvn eclipse:eclipse -DdownloadSources=true', an Eclipse project will be generated with sources or javadocs attached. Thanks, Tom. I've started using that flag. However, a surprising number of packages on ibiblio don't include source or javadoc archives. I've resorted to packaging up those jars manually and copying them directly to the local repo. If we ever get our act together and set up a workgroup repository that effort won't have to be duplicated on every workstation. -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: creating and using source archive
gdub wrote: gdub wrote: I have the source and javadoc archives going into the repository just fine but the eclipse plugin isn't picking them up when I execute the eclipse:eclipse goal. It was just a plugin version issue. The newest version picks up the sources just fine. It does not set the javadoc archive, though. Is that functionality supported by the plugin? -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
creating and using source archive
Good morning- We just completed our first Maven-based project and are on to the next. First, thanks to the Maven developers for their efforts and to the members of this list who were invariably helpful and patient during the newbie days. So, we are moving from the "let's see how Maven works" phase to the "let's look at the impact of Maven" phase. Personally, I have grown from "Maven child" to "Maven rebellious teenager." Now, a thing that would really cut time would be to have source and javadoc archives available in the local repository--for all local and 3rd- party artifacts. So my question is, how can I automatically install source and javadoc jars from development projects to the local repository? I see the instructions on how to upload them to ibiblio and I can successfully use the source:jar and javadoc:jar goals. But how do I get those jars into my local repository using Maven?. I know I can copy them directly but hopefully that's not the recommended means. Ideally, I'd like it configured so that building the install goal installs those jars as well. On the comment side, I would like to plead with ibiblio uploaders to please include source and javadoc archives with your packages if at all possible. I know it's extra work but it could have a big impact on Maven usability. Thanks as always, -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jetty out of memory reloading spring app
Stephen Duncan wrote: Also look at the second question in this FAQ: http://tomcat.apache.org/faq/deployment.html It explains why reloading an app causes this problem to show up more quickly. The description sounds like it would apply to any container that uses multiple classloaders, not just Tomcat, so it's likely true for Jetty as well. That would explain it. I wonder why the difficulty with releasing unreferenced class loaders. -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jetty out of memory reloading spring app
I wrote: > It does say that it's PermGen space > memory that's the problem. I'll look > at the article you mention tomorrow > and see if it helps. I increased the perm memory to 128Mb as a responder on the blog suggested. MAVEN_OPTS='-XX:MaxPermSize=128m' Now, I'm not getting the out-of-memory errors. One new weirdness is that now almost every time a class definition changes, the Jetty plug-in has to be restarted to avoid cast exceptions. I wonder if by setting MAVEN_OPTS (which wasn't set before) in the environment, some implicit setting was changed. -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jetty out of memory reloading spring app
> Hi is this a problem with perm memory? if so I think it is > the same problem > Matt Railble describes on his blog: > http://raibledesigns.com/page/rd/20060419 Thank you, Rolf- It does say that it's PermGen space memory that's the problem. I'll look at the article you mention tomorrow and see if it helps. -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jetty out of memory reloading spring app
Thanks, Jan- > The jetty maven plugin is up to release beta14 > so I would give that a go and see if it helps > with your memory issue. I'll try that. > Are the spring jars explicitly on the plugin's > classpath or are they as dependencies of the > project? All dependencies are configured in Maven using the pom.xml dependencies section. I didn't even know the plug-in had its own classpath config options. -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jetty out of memory reloading spring app
I use the jetty6:run (6.0 beta 9) target to launch Jetty with my web app under integration. It has a not-too-extensive Spring/Hibernate configuration. Jetty detects code changes just fine but after maybe 10 reloads, it starts reporting out-of-memory problems and refuses to reload. The machine isn't out of memory so it's the JVM itself that hits a wall. Is this a known Jetty plug-in problem? Or should I be looking for memory leaks in Spring and Hibernate (or, e gads, my own code). Is there something I need to configure to make sure that Jetty releases all app objects before reloading? BTW, I also ran into out of memory problems under surefire when running integration tests but was able to solve it by using a singleton Spring application context as a class member. But it leads me to think that my Spring context isn't releasing everything when it stops being referenced (closing the context and explicitly setting all references to it null helped me get about 10 more tests in a run). This is really only an issue during this final integration phase so it's not too big a deal but it does stop the thought flow when it happens. It's also an appli- cation confidence issue but I will do some memory profiling later. TIA, -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: test cases failing in Maven but not Eclipse
Jakub Pawlowicz wrote: > Did you take a look at files in the > 'target/surefire-reports' directory of > your project? Wayne Fay wrote: > Have you tried mvn -X, it reports a lot more > data than -e. Perhaps you'll see something > strange with -X? Valerio Schiavoni wrote: > we spotted out that our tests were based > on the path of some resources only reachable > within eclipse Awesome! Thanks for the help everyone. It WAS a path problem. And the surefire- reports dir and -X flag let me track it down. So, the deal was that a Spring config- uration file wasn't found. It is a one- bean file that defines the data source. For the testing DB server, I made a specialized data source config. Because it was a one-off and only used in testing, I just put it in with the test sources. That was the problem. Eclipse copies resources from all source directories to the classpath directories. Maven only copies the resources from the resources directory to there. Thanks again all, -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
test cases failing in Maven but not Eclipse
I am trying to install a module that depends on Spring and Hibernate. All of those dependencies for the app are in that Maven project. The trouble is that the tests won't pass. They pass fine in Eclipse. All the rest of the modules for this project pass their tests in both Maven and Eclipse. I can't see where the trouble is because nothing is reported back on the failures. The console shows INFO lines saying that Spring is loading the configuration files (which are all classpath resources, BTW) but no indication of how the tests are failing--only a message before maven exits saying that all the tests have failed. I sprinkled some printlns into some test methods to see if the test methods were even entered--they are not (well, at least I don't think they are, maybe the standard output is being shunted). The -e switch only reports the surefire exception that there were failed tests. I don't think module dependencies are the issue because I am using eclipse: eclipse to generate them for Eclipse-- i.e. they are the same in both environments. How do I approach finding the source of this trouble? There doesn't appear to be enough information to track it down. -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using the Eclipse compiler under maven
I see messages that suggest that I can use the Eclipse compiler instead of the Sun compiler from within Maven. Is this true? Is there a con- figuration page somewhere? I can't seem to find it. I have run across a situation where the Eclipse compiler compiles my 1.5 code but the Sun compiler won't. I think that the Eclipse compiler is correct but whether or not that is the case, I'm in the 11th hour and would just like to install my modules and keep moving. TIA, -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configure ArrayList in POM
Mike Perham wrote: > > http://... > http://... > Thanks, Mike. Is configuration syntax like that specifically written into each each plug-in? Or does Maven somehow automatically discern that "link" is the element that holds list items for a property named "links?" I'm just wondering how one might determine the configuration syntax for a plug-in generally. Is it just convention or is there actually code that reflects on plug-in objects and uses property names to infer XML element names? -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
configure ArrayList in POM
When a plugin lists a configuration property of type ArrayList, how are values expressed in a POM? In particular, I want to use the links configuration of the javadoc plugin but when I do the simple thing--just put a URL in the configuration/links element-- Maven complains that I'm trying to assign a String to an ArrayList. Is there a document somewhere that contains a java-type-to-POM-lex mapping reference? TIA, -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
thoughts on project lifecycle and editor configs (was: eclipse plug-in now compiles project)
I've re-read the MECLIPSE-37 discussion and thought a bit about the bigger picture: Maybe the root of the problem is that plug-ins like eclipse are logically outside Maven's scope. Arguably, Maven as a project lifecycle management tool should not be concerned with how developers view and modify project source artifacts. A POM is an expression of project policy. Should that policy dictate how editing tools are used? A practical example of the problem of coupling these concerns would arise when two developers wish to use the same IDE but with different configurations. Putting any such configuration information into a POM makes a policy statement about how that particular IDE is used. But IDE configuration should be developer-specific, not project-specific. In the example, each developer would have to maintain her own POM or one of the developers would have to defer to the other developer's ways. Maybe the whole issue should be viewed from the other direction. That is, the artifact view/modify tools should use Maven as a service rather than having Maven try to incorporate, via plug-ins, v/m tool configuration into the project lifecycle. -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
eclipse plug-in now compiles project
Hi- I'm wondering if this is a bug or just intended new behavior. I also don't know if it is a plug-in issue or a Maven application issue. Recently, I installed 2.02 on my laptop (I use 2.01 at the office). The eclipse:eclipse target on the laptop tries (and fails) to compile my project. This doesn't occur on my office machine. What this means is that I can't take uncompilable code with me on the road without manually configuring eclipse. If this is an intended behavior, is there a property recognized by the eclipse plug-in that turns it off? TIA, -dub - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
