Re: Maven release plugin not honoring -Darguments
An FYI on the escaping/quoting as that's come up twice and isn't the issue.
public class Arguments {
public static void main(String[] args) {
for (String arg : args) {
System.out.printf([%s], arg);
}
System.out.println();
}
}
$ java Arguments mvn release:prepare -DdryRun=true
-Darguments=-DskipTests=true -DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true
-DfailIfNoTests=false]
$ java Arguments mvn release:prepare -DdryRun=true
-Darguments=-DskipTests=true -DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true
-DfailIfNoTests=false]
$ java Arguments mvn release:prepare -DdryRun=true
-Darguments=-DskipTests=true -DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true
-DfailIfNoTests=false]
$ java Arguments mvn release:prepare -DdryRun=true
-Darguments=-DskipTests=true' '-DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true
-DfailIfNoTests=false]
$ java Arguments mvn release:prepare -DdryRun=true
-Darguments=-DskipTests=true\ -DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true
-DfailIfNoTests=false]
The next one just to be goofy :)
$ java Arguments mvn release:prepare -DdryRun=true
-Dargum'en'ts=-Ds'k'ipTests=true\ -DfailIfNoTest's'=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true
-DfailIfNoTests=false]
And finally an actually broken one:
$ java Arguments mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true
-DfailIfNoTests=false
[mvn][release:prepare][-DdryRun=true][-Darguments=-DskipTests=true][-DfailIfNoTests=false]
The problem isn't with the plugin but the Apache parent pom. Thanks, Benson,
for the feedback on that. There're half dozen committers on that pom so I'm
not sure who has the objection to allowing -Darguments to be used.
I've created this jira and attached a patch. Hopefully we can either fix it or
document it as intentionally not working and give reasons and workarounds like
the ones you suggest. I'm fine with either outcome.
https://issues.apache.org/jira/browse/MPOM-35
On a side note,... Happy new year to all! :)
-David
On Dec 30, 2011, at 2:22 AM, Ansgar Konermann wrote:
Am 27.09.2011 14:48 schrieb David Blevins david.blev...@gmail.com:
Is it a known issue that the release plugin does not honor the
-Darguments?
Specifically, I'm attempting to:
mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true
-DfailIfNoTests=false
Try:
mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true
-DfailIfNoTests=false
Notice the slightly different quoting (before -Darguments). Works well for
me.
Best regards
Ansgar
It takes 40 minutes to get through a dryRun with tests on. We still have
several kinks in the build to work out before the release plugin will work,
so obviously running with tests on every dryRun is just making a hard task
impossible.
maven 3.0.3, apache-10 parent pom, maven-release-plugin 2.1
-David
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven release plugin not honoring -Darguments
On Tue, Sep 27, 2011 at 1:09 PM, David Blevins david.blev...@gmail.com wrote:
Did some more digging and it seems the issue is in the apache-10 parent pom.
If you alter it like so, the arguments are passed as expected:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.1/version
configuration
useReleaseProfilefalse/useReleaseProfile
goalsdeploy/goals
!--arguments-Papache-release/arguments--
arguments-Papache-release ${arguments}/arguments
/configuration
/plugin
Seems this is just a mistake as the full config as reported via -X contains
quite a bit of foo${foo}/foo style declarations. We likely just missed
it here.
Going to use a hacked parent pom for the moment but it would be great if we
could get an apache-11 pom out soonish.
This came up again. Posting so I don't forget to deal with it when I
have time. Will file an issue with a patch tomorrow unless someone
beats me to it.
-David
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Maven release plugin not honoring -Darguments
Is it a known issue that the release plugin does not honor the -Darguments? Specifically, I'm attempting to: mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true -DfailIfNoTests=false It takes 40 minutes to get through a dryRun with tests on. We still have several kinks in the build to work out before the release plugin will work, so obviously running with tests on every dryRun is just making a hard task impossible. maven 3.0.3, apache-10 parent pom, maven-release-plugin 2.1 -David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven release plugin not honoring -Darguments
That's not it, the quoting was fine. Even with a single argument with no
spaces to -Darguments it still does not work.
Did some more digging and it seems the issue is in the apache-10 parent pom.
If you alter it like so, the arguments are passed as expected:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.1/version
configuration
useReleaseProfilefalse/useReleaseProfile
goalsdeploy/goals
!--arguments-Papache-release/arguments--
arguments-Papache-release ${arguments}/arguments
/configuration
/plugin
Seems this is just a mistake as the full config as reported via -X contains
quite a bit of foo${foo}/foo style declarations. We likely just missed it
here.
Going to use a hacked parent pom for the moment but it would be great if we
could get an apache-11 pom out soonish.
-David
On Sep 27, 2011, at 10:54 AM, Stephen Connolly wrote:
you can if you understand shell escaping.
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 27 Sep 2011 17:58, David Jencks david_jen...@yahoo.com wrote:
IIRC you have to include your forked maven arguments in the release plugin
configuration under
arguments-DskipTests=true -DfailIfNoTests=false/arguments
Perhaps someone else can say _why_ the m-r-p is set up so you can't set
this on the command line?
thanks
david jencks
On Sep 27, 2011, at 5:40 AM, David Blevins wrote:
Is it a known issue that the release plugin does not honor the
-Darguments?
Specifically, I'm attempting to:
mvn release:prepare -DdryRun=true -Darguments=-DskipTests=true
-DfailIfNoTests=false
It takes 40 minutes to get through a dryRun with tests on. We still have
several kinks in the build to work out before the release plugin will work,
so obviously running with tests on every dryRun is just making a hard task
impossible.
maven 3.0.3, apache-10 parent pom, maven-release-plugin 2.1
-David
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Surefire-plugin and surefirebooter jars and Glassfish and EJB unit testing
ljnelson wrote: Now Ken Saks, spec author for EJB 3.1 is saying sure, whoops, Glassfish has a problem, it doesn't consult the *effective* classpath because it doesn't take into consideration Manifest.MF Class-Path entries. Fine. But *then *he says something WAY more troubling: that any classpath roots reachable by way of Surefire's booter jar's Manifest Class-Path entry aren't actually roots for new EJB modules. That is, the classpath defined by Manifest.MF Class-Path is somehow...special as regards scanning. I say: huh?! I bring this up here, because if he's right and that ends up being part of the spec, then the neat way that surefire deals with big classpaths could effectively break standardized EJB 3.1 unit/integration testing. That might lead to you wanting to change or otherwise mess with the way Surefire does classpath construction. Per spec you are also able to list the file paths of the jars you want scanned. So in the end you should be able to take that approach even if GlassFish can't find the jars on its own. The classes are there and loadable in the thread context classloader so if you explicitly point at the jars, all should be fine. In terms of Glassfish effectively changing the spec. If they want to limit their support to specific techniques for scanning and finding modules, that's their call. But it only affects their implementation and not the spec itself. The new Embedded EJB Container functionality in the spec is intentionally minimalistic so that vendors have adequate room figure out how to make it work with their architecture. This is just part of the expected challenges that vendors will face. -- View this message in context: http://old.nabble.com/Surefire-plugin-and-surefirebooter-jars-and-Glassfish-and-EJB-unit--testing-tp28184255p28185208.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JavaAgent support (SUREFIRE-179)
Yeah, I wasn't sure if that patch was still good (or if it ever was). Thanks for taking a look a it! -David On Nov 3, 2009, at 12:15 AM, Brett Porter wrote: I took a look and the patch is quite out of date and didn't apply straight up for me. It does have tests though so with any luck I'll get a closer look at the hackathon tomorrow. The good news (sort of) is that Surefire has very few changes committed since the last release, so a release should be reasonably straightforward. - Brett On 02/11/2009, at 1:44 PM, David Blevins wrote: Is there any committer out there who has the time to review and commit this patch? Would be happy to issue a thank you blog post in the OpenEJB blog to the committer who gets this functionality in :) Would be a big bonus for OpenEJB/OpenJPA unit testers to get this or something like it in. -David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
JavaAgent support (SUREFIRE-179)
Is there any committer out there who has the time to review and commit this patch? Would be happy to issue a thank you blog post in the OpenEJB blog to the committer who gets this functionality in :) Would be a big bonus for OpenEJB/OpenJPA unit testers to get this or something like it in. -David - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Please UnSubscribe
Hi Durga,
I think your information is bad. I and most the people on this list
don't have admin on this list -- seems the list is related to Codehaus
which is a different organization like Eclipse or Java.net.
Try clicking this link (hoping your email client makes it clickable):
mailto:dev-unsubscr...@maven.apache.org
If you send it from the email address you listed it *should* work.
Don't need to fill in anything special for the subject or body.
Hope this helps!
-David
On Jul 8, 2009, at 11:42 AM, Durga Deep Tirunagari wrote:
can one of the people listed in here ( with no clickable e-mail
address ). Remove me from this user list ?
E-mail (durga.tirunag...@sun.com )
http://jira.codehaus.org/secure/Administrators.jspa
System Administrators
Here is the list of system administrators for this installation of
JIRA.
System Administrators have complete administrative rights including
permission to manage underlying JIRA system configuration such as
backups and services.
* Alan Cabrera
* Andrew Eisenberg
* Arnaud Heritier
* Ben Walding
* bob mcwhirter
* Brett Porter
* Brian Topping
* Bruce Snyder
* Contegix Support
* Dain Sundstrom
* Dan Diephouse
* Dan North
* David Blevins
* Dennis Lundberg
* Edward Povazan
* Emmanuel Venisse
* Eugene Kuleshov
* Guillaume Laforge
* Jacques Morel
* James E. Ervin
* James Macgill
* Jason Dillon
* Jason van Zyl
* Jody Garnett
* Paul Hammant
* Peter Donald
* peter royal
* Rodrigo B. de Oliveira
* Scott Farquhar
* Trygve Laugstol
* Vincent Massol
* Werner Guttmann
* Xircles System User
Thanks a bunch
On Jul 8, 2009, at 11:38 AM, Benjamin Bentmann (JIRA) wrote:
[ http://jira.codehaus.org/browse/MNG-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=182983#action_182983
]
Benjamin Bentmann commented on MNG-4232:
In which file exactly does this substitution happen? In the POM or
in some resource file? Could you provide an example project to
demonstrate this?
Property substitution of ${project.build.directory} on Windows FAILS
Key: MNG-4232
URL: http://jira.codehaus.org/browse/MNG-4232
Project: Maven 2
Issue Type: Bug
Components: Bootstrap Build
Affects Versions: 2.2.0
Environment: Windows XP 32 bits
Reporter: Rodolfo Rothganger
For a project target directory on C:\project\target, the maven
build substitutes the project property ${project.build.directory}
with c\:\\project\\target. The c\:\\ should be c:\\
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Reports are down
A patch would be great! Sent from my iPhone On Dec 7, 2008, at 1:36 AM, Arnaud HERITIER [EMAIL PROTECTED] wrote: Hi, Our reports on votes are down : http://www.sonatype.org/~j2ee-hudson/reports/ https://ci.sonatype.org/view/Reports/ It's certainly a Jira upgrade which broke the xml-rpc API used in Swizzle but there was no activity on this project to fix the issue (and since april). Is there someone who know the swizzle team ? Is it useful to spend time to provide a patch ? -- .. Arnaud HERITIER 12 guidelines to boost your productivity with a Java software factory - http://tinyurl.com/56s9tw .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Surefire support for a javaagent
Currently, it's a bit of a trick trying to get a javaagent in use with your test cases. Here's the boiler plate pom text: http://cwiki.apache.org/OPENEJBx30/javaagent-with-maven-surefire.html It'd be really great if we could just do it like this: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId configuration forkModepertest/forkMode javaagent groupIdorg.apache.openejb/groupId artifactIdopenejb-javaagent/artifactId version3.0/version optionsthe optional javaagent options string/options /javaagent /configuration /plugin The plugin could get the path to the artifact in the local repo and prepend the string -javaagent:jarpath[=options] to the value of argLine if there is one, similar to how the classpath is created. Seems like we could just take part of the maven-dependency-plugin and reuse it in the surefire plugin. I've hacked on some plugins before, but the surefire one seems a little more complicated than the typical plugin. Anyone with some surefire expertise interested in working on this? -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SURVEY][RESULT] Which plugin would you like us to release?
On Aug 10, 2008, at 9:54 AM, Jason van Zyl wrote: Dennis, Just a follow up on the reports. The reports generated by Swizzle are here (I restored them): https://svn.apache.org/repos/asf/maven/sandbox/trunk/reports And they are checked out in the home directory of Hudson on the CI server. Also note that whatever reports we come up we can ultimately embed in Confluence as David wrote a Confluence macro for this stuff. I would just want to check if there is caching because having the actual reporting logic run every time you hit the page would be bad. It caches for an hour, which may not be enough. Can't remember if it's configurable. -David On 8-Aug-08, at 12:44 PM, Jason van Zyl wrote: Dennis, If you're interested and want to use this in conjunction with your surveys: I created a panel in Hudson: http://ci.sonatype.org/view/Reports/ There is a Plugin Votes Report, and when you trigger the job it will render this: http://www.sonatype.org/~j2ee-hudson/reports/plugin-votes.txt They just use Swizzle (which is very handy) so any types of reports you think might help make the releases more user focused just let me know. On 7-Aug-08, at 1:59 PM, Dennis Lundberg wrote: The survey has been open for a week now and has now been closed. Thanks to the 47 people who took the survey! Here are the top 5 five most wanted plugin releases: Plugin Response Percent war 12.8% release 12.8% enforcer10.6% scm 10.6% assembly 8.5% Dennis Lundberg wrote: Hello everyone I'm going to try something new here. It's an experiment and we'll see how it goes. I have set up a very simple survey over at SurveyMonkey, to get a feel for what you, our users, want us to do next when it comes to plugin releases. Remember, this is *not* about fixing issues - it's about getting releases out. So please help us help you, by answering this one question survey: http://www.surveymonkey.com/s.aspx?sm=M6IB7I_2fVmpKddfv1oCM_2few_3d_3d -- Dennis Lundberg - 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 -- First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - 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 -- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: roadmap for maven-shade-plugin?
On Jul 21, 2008, at 8:55 AM, Daniel Kulp wrote: I think it's OK to do a release of it now, especially if it's blocking 2.0.10. I've tested it with CXF and it looks OK there. No regressions in the dep-reduced pom. It would be NICE if the OpenEJB folks could do a quick test with their code, but I wouldn't hold it up for that to occur. Tried it with some of the OpenEJB stuff and everything looked good. -David On Jul 21, 2008, at 11:35 AM, John Casey wrote: Hi everyone, I'd like to check and see how close people think we're getting to a release of the maven-shade-plugin. I understand there are some outstanding issues related to excludes, but at this point the pending 1.2 release is blocking the maven 2.0.10 release. Can we talk about specific issues that are waiting for 1.2, and who's working on what? Thanks, -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.ejlife.net/blogs/buildchimp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog - 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: XBean and DI?
On Mar 14, 2008, at 8:24 AM, Jason van Zyl wrote: The additions Dain has made to XBean adds things I was just never interested in like constructor injection and bean factories. Also xbean-reflect thinks in java.lang.reflect.Type terms so it's easy to add converters that are generics-aware. For example I recently added converters for MapK,V and SetT and ListT and it only took an hour. Just in general the code is pretty small and tight as well and generally very easy to add features. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tree/graph of Artifact objects
On Jan 29, 2008, at 10:48 AM, Carlos Sanchez wrote: if you want something graphical take a look at http://code.google.com/p/maven-dependency-browser/ it's going to be integrated in Q4E http://code.google.com/p/q4e/issues/detail?id=144 Graph as in the data structure, but thanks :) -David On Jan 18, 2008 12:15 PM, David Blevins [EMAIL PROTECTED] wrote: Is there any way to get or make a tree of Artifact objects? I've tried taking the list of Artifacts returned from project.getArtifacts(), then wrapping them in my own node object and relinking them via the info in the dependency trail. This works fine except that there is some information loss. Say two artifacts (a and b) each depend on a thrid artifact (c). The c dependency will have only one dependency trail showing either a or b and i'd like to see both trails. I don't really need this info from the dependency trail specifically, just want some way to get the whole graph with no loss in relationships. Any ideas? -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - 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]
project level exclusions
It occurs to me I'd really like the ability to apply exclusions at a more general level than each individual dep. We have ton of excludes (136), some deps want to pull in the world, and a very good chunk of them are redundant. Doing a grep/sort/uniq looks like 68 of them are redundant. We use the dependencyManagement section in our parent pom quite a bit (most our excludes are there), but perhaps it would be logical also use the dependencyManagement, which simplifies inclusion, to simplify exclusion as well. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tree/graph of Artifact objects
On Jan 22, 2008, at 6:49 AM, Mark Hobson wrote: Hi David, On 19/01/2008, David Blevins [EMAIL PROTECTED] wrote: Still digging through that code, but hopefully you can answer this question real quick. The resulting structure is definitely a tree as opposed to a graph (which could be fine). Does that mean given the A and B depend on C scenario I described, there'll be two copies of C; one C below A with A as it's parentNode, and one C below B with B as it's parent node? If the answer is yes, then I can easily re-arrange things to a graph (multi-parent nodes). If no, then can you confirm my suspicion that I could achieve what I'm after with a slightly varied version of DependencyTreeResolutionListener? maven-dependency-tree does indeed build a tree as opposed to a graph. You could implement a ResolutionListener that built a graph instead and ignored all the omit events, but if you ultimately also require the dependency resolutions from Maven then I'd advise adding optional graph functionality to maven-dependency-tree, since the resolution events are rather delicate (see DependencyTreeResolutionListener). Note that Jason is coordinating a lot of future work in this direction for 2.1, which will use graphs natively to resolve dependencies rather than events. So far the tree seems to have enough data in it that it can be rewrapped as a graph. I have wrapper similar to DependencyNode that has multiple parents. Anywhere a child is a duplicate or conflict it's replaced by the wrapper of the related artifact and a new parent added to the list. Relatively straight forward. I could add it back into the maven- dependency-tree lib if you think it's particularly useful. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tree/graph of Artifact objects
Is there any way to get or make a tree of Artifact objects? I've tried taking the list of Artifacts returned from project.getArtifacts(), then wrapping them in my own node object and relinking them via the info in the dependency trail. This works fine except that there is some information loss. Say two artifacts (a and b) each depend on a thrid artifact (c). The c dependency will have only one dependency trail showing either a or b and i'd like to see both trails. I don't really need this info from the dependency trail specifically, just want some way to get the whole graph with no loss in relationships. Any ideas? -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release maven-shade-plugin 1.0-beta-1
dkulp wrote: I'd like to release maven-shade-plugin 1.0-beta-1 as I kind of need it for some of my projects. I think Geronimo may need it as well. OpenEJB, actually. And here's my +1! (non-binding) -David -- View this message in context: http://www.nabble.com/-VOTE--release-maven-shade-plugin-1.0-beta-1-tp14892803s177p14942018.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Shade improvement: filtering
I need the ability to include/exclude classes from certain artifacts when creating the shaded jar. In OpenEJB we have a situation where one of the jars we are adding to the shaded jar contains a class also part of another jar added to the shade. The class in question truly belongs to one of the jars and as only added to the other jar for convenience. I need the ability to either include/exclude classes from jars, or a flat to tolerate duplicates. I've implemented the more robust approach of including/excluding from specific artifacts as ideally I'd like to be able to say strictly this jar can only 'export' this package'. Happy to make any suggested tweaks. http://jira.codehaus.org/browse/MSHADE-12 I can implement a simpler approach which just allows one to ignore duplicates if that'd be desired instead. And as an aside, I have commit privileges but that was through involvement in Continuum. I'd like a nod from someone involved with the Shade plugin before committing. Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shade improvement: filtering
Thanks for reviewing! On Jan 15, 2008, at 6:09 PM, Daniel Kulp wrote: David, I'm OK with you committing this except for a few minor nits: 1) Javadoc for the parameter you added. The description about the includes/excludes needs to be added to the javadoc for the parameter so the generated site has that information. Will do. 2) Code formatting isn't quite right for maven. Maven's style puts spaces all over the place. The code you added doesn't match that. Sure, is there a style guide somewhere? Tried to eye-ball it obviously. 3) It definitely won't work for the source jar. You only added the isFiltered stuff in to the endsWith(.class) part, but not the other clause of the if. Most likely, the entire if/else should be surrounded by your check. So likely something like: -if ( !entry.isDirectory() ) +if ( !entry.isDirectory() !isFiltered(jarFilters, name)) Which would prevent any addDirectory, addRemappedClass, or addResource calls. Could wrap that one if/else but then we'd still get directories from excluded resources/classes. -David On Tuesday 15 January 2008, David Blevins wrote: I need the ability to include/exclude classes from certain artifacts when creating the shaded jar. In OpenEJB we have a situation where one of the jars we are adding to the shaded jar contains a class also part of another jar added to the shade. The class in question truly belongs to one of the jars and as only added to the other jar for convenience. I need the ability to either include/exclude classes from jars, or a flat to tolerate duplicates. I've implemented the more robust approach of including/excluding from specific artifacts as ideally I'd like to be able to say strictly this jar can only 'export' this package'. Happy to make any suggested tweaks. http://jira.codehaus.org/browse/MSHADE-12 I can implement a simpler approach which just allows one to ignore duplicates if that'd be desired instead. And as an aside, I have commit privileges but that was through involvement in Continuum. I'd like a nod from someone involved with the Shade plugin before committing. Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - 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: Shade improvement: filtering
On Jan 15, 2008, at 6:47 PM, David Blevins wrote: Thanks for reviewing! On Jan 15, 2008, at 6:09 PM, Daniel Kulp wrote: David, I'm OK with you committing this except for a few minor nits: 1) Javadoc for the parameter you added. The description about the includes/excludes needs to be added to the javadoc for the parameter so the generated site has that information. Will do. Done. Also added some content to the examples.apt. 2) Code formatting isn't quite right for maven. Maven's style puts spaces all over the place. The code you added doesn't match that. Sure, is there a style guide somewhere? Tried to eye-ball it obviously. Found the related intellij config file and fixed the styling. 3) It definitely won't work for the source jar. You only added the isFiltered stuff in to the endsWith(.class) part, but not the other clause of the if. Most likely, the entire if/else should be surrounded by your check. So likely something like: -if ( !entry.isDirectory() ) +if ( !entry.isDirectory() !isFiltered(jarFilters, name)) Which would prevent any addDirectory, addRemappedClass, or addResource calls. Could wrap that one if/else but then we'd still get directories from excluded resources/classes. Implemented it like this. Renammed ClassFilter to ArchiveFilter as it now applies to more than just classes. All checked in and ready to go. Updated and closed the MSHADE-12 so it should show up in the 1.0-beta-1 release notes. Thanks! -David On Tuesday 15 January 2008, David Blevins wrote: I need the ability to include/exclude classes from certain artifacts when creating the shaded jar. In OpenEJB we have a situation where one of the jars we are adding to the shaded jar contains a class also part of another jar added to the shade. The class in question truly belongs to one of the jars and as only added to the other jar for convenience. I need the ability to either include/exclude classes from jars, or a flat to tolerate duplicates. I've implemented the more robust approach of including/excluding from specific artifacts as ideally I'd like to be able to say strictly this jar can only 'export' this package'. Happy to make any suggested tweaks. http://jira.codehaus.org/browse/MSHADE-12 I can implement a simpler approach which just allows one to ignore duplicates if that'd be desired instead. And as an aside, I have commit privileges but that was through involvement in Continuum. I'd like a nod from someone involved with the Shade plugin before committing. Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - 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: Shade improvement: filtering
Mauro, is it possible you can publish a new snapshot or update the perms on the metadata files? -David On Jan 15, 2008, at 9:02 PM, David Blevins wrote: On Jan 15, 2008, at 6:47 PM, David Blevins wrote: Thanks for reviewing! On Jan 15, 2008, at 6:09 PM, Daniel Kulp wrote: David, I'm OK with you committing this except for a few minor nits: 1) Javadoc for the parameter you added. The description about the includes/excludes needs to be added to the javadoc for the parameter so the generated site has that information. Will do. Done. Also added some content to the examples.apt. 2) Code formatting isn't quite right for maven. Maven's style puts spaces all over the place. The code you added doesn't match that. Sure, is there a style guide somewhere? Tried to eye-ball it obviously. Found the related intellij config file and fixed the styling. 3) It definitely won't work for the source jar. You only added the isFiltered stuff in to the endsWith(.class) part, but not the other clause of the if. Most likely, the entire if/else should be surrounded by your check. So likely something like: -if ( !entry.isDirectory() ) +if ( !entry.isDirectory() !isFiltered(jarFilters, name)) Which would prevent any addDirectory, addRemappedClass, or addResource calls. Could wrap that one if/else but then we'd still get directories from excluded resources/classes. Implemented it like this. Renammed ClassFilter to ArchiveFilter as it now applies to more than just classes. All checked in and ready to go. Updated and closed the MSHADE-12 so it should show up in the 1.0-beta-1 release notes. Thanks! -David On Tuesday 15 January 2008, David Blevins wrote: I need the ability to include/exclude classes from certain artifacts when creating the shaded jar. In OpenEJB we have a situation where one of the jars we are adding to the shaded jar contains a class also part of another jar added to the shade. The class in question truly belongs to one of the jars and as only added to the other jar for convenience. I need the ability to either include/exclude classes from jars, or a flat to tolerate duplicates. I've implemented the more robust approach of including/excluding from specific artifacts as ideally I'd like to be able to say strictly this jar can only 'export' this package'. Happy to make any suggested tweaks. http://jira.codehaus.org/browse/MSHADE-12 I can implement a simpler approach which just allows one to ignore duplicates if that'd be desired instead. And as an aside, I have commit privileges but that was through involvement in Continuum. I'd like a nod from someone involved with the Shade plugin before committing. Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [Take 2] Release Maven Surefire version 2.4
dfabulich wrote: Vote open for 72 hours. PS Since it's so close to the Gregorian New Year, I'm probably not going to actually deploy the release until Jan 3 at the earliest, even if the vote passes. :-) Where are things at with this? Looking to cut a release of OpenEJB which is using surefire-2.4-SNAPSHOT at the moment. Thanks, David -- View this message in context: http://www.nabble.com/-VOTE---Take-2--Release-Maven-Surefire-version-2.4-tp14509835s177p14703705.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: confluence (was: We're near the release of 1.0 final)
On Mar 29, 2007, at 6:19 PM, Jeff Jensen wrote: Just not understanding yet the Maven plans for wiki/site usage. My fear, obviously, is continued separate works, as some people I helped with Maven have a not happy-out-of- the-box experience, which includes scattered docs - I always have to give them multiple URLs for info and/or they keep Googling for answers. If you plan to integrate Maven site and the wiki so well like the examples you provided, then the user sees them as one source. Very nice. Just a note on this aspect too. I have a confluence client library which could be used in a plugin that automatically exports some or all of the confluence content for inclusion in other works -- releases, etc. Might be some other fun things you with the ability to easily read/write data from confluence. Some javadoc here: http://swizzle.codehaus.org/swizzle-confluence/ -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: distributed continuum
On Sep 24, 2006, at 11:41 PM, Jason van Zyl wrote: On 25 Sep 06, at 1:44 AM 25 Sep 06, Brett Porter wrote: Cool bananas. Welcome David! Yah, I know from David that's it's been working for quite a while so I figured let David and Kevan work on it in the trunk where it will get some visibility and help. I'm sure that lots of people are going to be interested in this feature. Coupled with build parallelization and some staged commit capabilities this will be quite an amazing new feature. Thanks for the welcome guys. Going to try and get myself familiar with trunk again. Last time I looked at it heavily was Oct, Nov, Dec. Just off the top of my head, I know there's been tons of work in security and the webwork stuff. Do you guys think it's unreasonable to try and put up an install of Continuum trunk to run a few projects? Is trunk basically functional at this point? -David On 25/09/2006, at 7:37 AM, Jason van Zyl wrote: Howdy, As we discussed some time ago, I was going to check in the distributed continuum once it built and it does with trunk. So I checked it in so that David Blevins can help me with some tests. David now has access as we agreed some time ago. Jason. Jason van Zyl [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED]
Building and running?
So the README.txt is obviously out of date. What's the status on building and starting up a continuum server? -David
Re: Common API for issue tracking systems
A bit ago a created a client for Jira which may be useful: http://docs.codehaus.org/display/SWIZZLE/Swizzle+Jira http://swizzle.codehaus.org/swizzle-jira/ -David On Jul 3, 2006, at 9:17 AM, Vincent Massol wrote: +1. Actually I thought there was already a project for this but I was probably anticipating... * SCM for SCMs * Wagon for transports * Cargo for containers ... Spoor for bug trackers (or whatever other name!) -Vincent -Original Message- From: Mark Hobson [mailto:[EMAIL PROTECTED] Sent: lundi 3 juillet 2006 18:08 To: Maven Developers List Subject: Common API for issue tracking systems Hi there, I was wondering whether any thought had been given to an abstract issue tracking API with implementations for Bugzilla, JIRA, etc.? I can see a couple of uses within maven: * Querying the issues fixed when releasing a new version of a project, to be used within the maven-changes-plugin * Creating a new version of a product in the underlying issue tracking system when releasing a new version of a project I couldn't see this abstraction in the maven-changes-plugin, but correct me if I'm wrong. I've recently written some code to programmatically manipulate Bugzilla, and thought this could be expanded into a general-purpose abstract API for manipulating issue tracking systems. Rather like Wagon is to transports and SCM is to SCMs. It'd be good to see Bugzilla support within maven and I'd be interested in people's thoughts. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ _ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.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: Non-public projects
Woohoo. So what's the status of 1.1 these days? -David On Apr 13, 2006, at 12:08 PM, Emmanuel Venisse wrote: Yes, it will be in 1.1. Emmanuel Carlos Sanchez a écrit : I think this is what it's planned for 1.1 by adding security through Acegi On 4/13/06, David Blevins [EMAIL PROTECTED] wrote: There is a new feature I need and I'd like to get feedback from the group on how it may be implemented. Don't know if I'll end up writing, but at least I'd like to get some discussion going for now. We at Geronimo desperately need to be able to setup a couple projects in continuum that aren't public -- they're tck related. So basically, we need some way to mark a project as viewable by only logged in individuals in a specific group. Having them listed on the main page with the other projects is ok, just clicking on anything there should require you to be properly authenticated and authorized to do so. This is a big new can of worms for Continuum, so what does everyone think? Good feature/bad feature? Any thought's on what'd be required to implement it? -David -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Non-public projects
Sure, was thinking more high-level. Last I knew 1.1 was torn up and at the beginning of a webwork (or something) conversion. I guess the better phrasing is what state is 1.1 in these days? -David On Apr 13, 2006, at 12:38 PM, Emmanuel Venisse wrote: 1.1 development is suspended until the release of 1.0.3 in few days. We don't have for the moment a release date for 1.1 Emmanuel David Blevins a écrit : Woohoo. So what's the status of 1.1 these days? -David On Apr 13, 2006, at 12:08 PM, Emmanuel Venisse wrote: Yes, it will be in 1.1. Emmanuel Carlos Sanchez a écrit : I think this is what it's planned for 1.1 by adding security through Acegi On 4/13/06, David Blevins [EMAIL PROTECTED] wrote: There is a new feature I need and I'd like to get feedback from the group on how it may be implemented. Don't know if I'll end up writing, but at least I'd like to get some discussion going for now. We at Geronimo desperately need to be able to setup a couple projects in continuum that aren't public -- they're tck related. So basically, we need some way to mark a project as viewable by only logged in individuals in a specific group. Having them listed on the main page with the other projects is ok, just clicking on anything there should require you to be properly authenticated and authorized to do so. This is a big new can of worms for Continuum, so what does everyone think? Good feature/bad feature? Any thought's on what'd be required to implement it? -David -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Creating a notifier for Confluence
FYI, I have a library available for manipulating Confluence via XML-RPC http://cvs.codehaus.org/viewrep/swizzle/swizzle/swizzle-confluence/ src/main/java/org/codehaus/swizzle/confluence You are unlikely to find anything more complete. I have another one for Jira as well. Binaries are available here: http://snapshot.repository.codehaus.org/org/codehaus/swizzle/ Can put out a final if you like. -David On Apr 5, 2006, at 12:39 AM, Emmanuel Venisse wrote: Yes, you need to extends AbstractContinuumNotifier. You can look at MailContinuumNotifier, IrcContinuumNotifier, JabberContinuumNotifier and MsnContinuumNotifier for samples When your notifier will be implemented, do you want to donate it to us? Emmanuel Mang Jun Lau a écrit : Hi, Our company uses Atlassian Confluence as a wiki. I want to try to create a notifier so that after a build, the notification is sent as a message to post on a Confluence page. Since you can post to Confluence via SOAP web services calls, I think may be straightforward to create a notifier. Where do I look to start and what are some of the requirements? Do I simply extend AbstractContinuumNotifier or what? Any direction would help. Thanks. _Mang Lau
Re: Creating a notifier for Confluence
On Apr 5, 2006, at 8:23 PM, David Blevins wrote: On Apr 5, 2006, at 7:29 AM, Emmanuel Venisse wrote: I think the best way it to create a wrapper on it like we do it for irc (with plexus-irc) and jabber (with plexus-jabber) and use use the wrapper in the notifier. But perhaps, it isn't necessary, i didn't look at swizzle. http://docs.codehaus.org/display/SWIZZLE/Swizzle+Confluence That just shows reading from a space, but you can add/update pages too. Here is some javadoc: http://swizzle.codehaus.org/swizzle-confluence/ -David
Re: Rss notifier
On Mar 27, 2006, at 12:25 AM, Adam Leggett wrote: Im working on an Rss notifier for continuum. Ive added a comment to CONTINUUM-418 to see if this would be a useful contrib. In the meantime prior to submitting any patch or feature I have to decide which baselined version of the source to use to incorporate the feature in the short term (rather than the current trunk). Ive looked around for a source distribution for 1.0.2/3 but cannot find it. So Ive used tags from svn. Which tag/branch/source distribution would anyone recommend I use as a baseline? The 1.0.3 branch lives here http://svn.apache.org/repos/asf/maven/ continuum/branches/continuum-1.0.x Can't wait to see some RSS ability in Continuum! -David
Re: Distributed Continuum (GBuild)
Nice diagram! Minus javaspaces and JMS in it's place, that's pretty much what we've got. -David On Mar 24, 2006, at 8:49 AM, Vincent Massol wrote: Big +1 too. I've also been waiting for it, see http://tinyurl.com/ 42zc7 :-) Thanks -Vincent -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: mercredi 22 mars 2006 22:13 To: continuum-dev@maven.apache.org Subject: Re: Distributed Continuum (GBuild) +1. I've been really looking forward to it. Jason van Zyl wrote: Hi, I have been talking with David Blevins about moving the GBuild code from Geronimo over to Continuum proper. GBuild is a version of Continuum that works in a distributed fashion. GBuild was created to test the Geronimo TCK across many different platforms with many different configurations and have the results all aggregated back on a master machine. So what I would like to propose is to move the code from GBuild over into Continuum proper and give David Blevins and Kevan Miller commit access. They are both committers on the Geronimo project and are familiar with this distributed code and will continue to work on the code once in Continuum. This is very exciting! Here's my +1 Jason van Zyl
Archive layout created by maven-assembly-plugin
I need to create an assembly that doesn't put everything under a artifactId-version style directory; meaning I want it to unzip right into ./ with no directory prefix such as: $ unzip openejb-tomcat-3.0.1.zip deflating ... ./conf/openejb.xml ./server/lib/openejb-core-3.0.1.jar ./server/lib/openejb-ejbd-3.0.1.jar ./server/lib/openejb-server-3.0.1.jar Is that possible with the maven-assembly-plugin? -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jdk 1.4 and 1.5 in same install?
We're not going enforce a forked-compiler/forked-tests hack on any projects that want to run in gbuild. That's the maven 1 way to solve problems. I'll setup another continuum install at some point and happily wait for the right feature. -David. On Feb 20, 2006, at 1:38 AM, Emmanuel Venisse wrote: What about carlos's suggestion? I'm sorry, but i can't include continuum profiles in 1.0.3 Emmanuel David Blevins a écrit : We have too much corba tie-in to the Sun ORB which makes it so we can't compile a few chunks of the code or test it on anything other than strict 1.4 vm (no 1.5 with 1.4 flags). -David On Feb 8, 2006, at 11:08 PM, Emmanuel Venisse wrote: An other option is to set source and target argument on compiler plugin David Blevins a écrit : Sounds like a scary m1-style hack ... not going there. Second install it is -David On Feb 8, 2006, at 1:34 PM, Carlos Sanchez wrote: What about compiler and test plugins options like fork, executable, ... On 2/8/06, David Blevins [EMAIL PROTECTED] wrote: So i find myself needing jdk 1.4 for 90% of what i have in the geronimo continuum install, some of those actually can't compile with 1.5 because of corba/vm ties. But alas I do need 1.5 now for at least two projects. Do i pretty much have to setup another continuum install for this? -David
Re: jdk 1.4 and 1.5 in same install?
We have too much corba tie-in to the Sun ORB which makes it so we can't compile a few chunks of the code or test it on anything other than strict 1.4 vm (no 1.5 with 1.4 flags). -David On Feb 8, 2006, at 11:08 PM, Emmanuel Venisse wrote: An other option is to set source and target argument on compiler plugin David Blevins a écrit : Sounds like a scary m1-style hack ... not going there. Second install it is -David On Feb 8, 2006, at 1:34 PM, Carlos Sanchez wrote: What about compiler and test plugins options like fork, executable, ... On 2/8/06, David Blevins [EMAIL PROTECTED] wrote: So i find myself needing jdk 1.4 for 90% of what i have in the geronimo continuum install, some of those actually can't compile with 1.5 because of corba/vm ties. But alas I do need 1.5 now for at least two projects. Do i pretty much have to setup another continuum install for this? -David
[jira] Commented: (CONTINUUM-419) Can't click to see the latest build results from the main page
[ http://jira.codehaus.org/browse/CONTINUUM-419?page=comments#action_58739 ] David Blevins commented on CONTINUUM-419: - And failed builds. I noticed you now get a link on successful builds. Not to concerned about checking why something was successful :) A link for the latest build especially when there is an in progress or failed build is what I want. That's pretty much the only time i care to see the build output. Can't click to see the latest build results from the main page -- Key: CONTINUUM-419 URL: http://jira.codehaus.org/browse/CONTINUUM-419 Project: Continuum Type: Improvement Components: Web interface Versions: 1.0 Reporter: David Blevins Priority: Trivial When you are at the projects page (Summary.vm/fid/continuumProject) it's really annoying you can't just click somewhere and see the latest build results. You have to click Build History then the top results item, which is a big of traveling. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
jdk 1.4 and 1.5 in same install?
So i find myself needing jdk 1.4 for 90% of what i have in the geronimo continuum install, some of those actually can't compile with 1.5 because of corba/vm ties. But alas I do need 1.5 now for at least two projects. Do i pretty much have to setup another continuum install for this? -David
Re: Security in Continuum
I like this more and more. -David On Jan 14, 2006, at 6:12 AM, Trygve Laugstøl wrote: On Wed, 2006-01-11 at 19:13 +0100, Emmanuel Venisse wrote: Hi, In 1.1, we have decided to rework all security features. I haven't looked at osuser in particular yet, but I still think it might work for us. Anyway I'm suggesting the following strategy: 1) Make a set of Continuum-specific interfaces: * ContinuumAuthentication has a login( username, password ) and a logout() method * ContinuumAuthorization canExecute( authenticationToken, protectedResourceId ) * ContinuumUserManager User and Group object CRUD methods, addUserToGroup() and the likes. 2) Make a LDAP implementation of these interfaces and include Apache Directory in Continuum as the default database or write a Derby- specific implementation as that's what we're already shipping with. The advantage by including Directory is that we have one less implementation to write and it's easier to migrate to a proper LDAP database as you can connect to the Directory service and dump the existing database. The disadvantage is the increased size of the Continuum binary distribution. I'm currently not sure how big the Directory server is in terms of bytes. The binary ApacheDS distro [1] is 10MB but I really doubt all of that is required. It shouldn't be really hard to write a Derby implementation and it will probably be the fastest implementation. By following this strategy we isolate Continuum from the implementation as the interfaces are Continuum-oriented and should be pretty stable from day one, and we can add JAAS implementations later on. By having a standalone (Derby), LDAP and JAAS implementation I think that we've covered all possible integration points. I'd guess that 90% of all people wanting authenticate with an external system would use LDAP anyway. Thoughts? [1]: http://cvs.apache.org/dist/directory/apacheds/ -- Trygve
Re: Security in Continuum
On Jan 13, 2006, at 6:58 AM, John Casey wrote: Looks like this isn't an option unless we can make it work on Windows... Darn. I shot a note off to Greg the JPam guy to see what he's got going on there. At the very least, we use the API that Trygve proposes and create an implementation for JPam if someone really wants it. -David From the documentation: Jpam can be used on: 1. Linux x86 2. Linux x86_64, including AMD64 3. Mac OS X 4. Solaris sparc PAM is used on Unix and Unix-like operating systems. JPAM should be readily portable to other *nixes. -john David Blevins wrote: On Jan 12, 2006, at 2:25 PM, Emmanuel Venisse wrote: David Blevins a écrit : On Jan 11, 2006, at 10:13 AM, Emmanuel Venisse wrote: Hi, In 1.1, we have decided to rework all security features. I tried to use osuser but this framework is crappy : [...] I looked at seraph too. This project seems to be interesting, it's used by confluence and jira. It seems we have all we need in it but it require to be used in a web app environment, so i think we can't use it if we want to use security framework in a standalone app in future. Interesting, if you look at the dependencies for seraph, it's clearly using osuser. - http://opensource.atlassian.com/seraph/dependencies.html osuser is use only for the DefaultAuthenticator, if you don't use it, you don't need osuser. Wonder if writing our own option couldn't mean writing our own wrapper for osuser. not exactly. osuser would can be supported by a provider of our own. But if we decide to write it, it must be extensible with providers like other framework(osuser, seraph...) and ldap, jaas... I can't believe i forgot about this. http://jpam.sourceforge.net/documentation/ Then we could do real security and not java-toy security only usable by continuum. I've got a shared LDAP directory up on ci.gbuild.org right now which we use instead of /etc/passwd files for logging into the various gbuild machines. There is a j2eetck group that we put people in if they are allowed to see tck related stuff. Would be excellent if we could use that exact setup in continuum to lock off certain projects to only be visible to that or other groups. I've had to setup cron jobs to build the various things that are tck private -- made an attempt to put up a non-public continuum install for that, but it was too much of a pain. -David Emmanuel
gbuild: maven scm updater issue
I seem to have gotten a bad snapshot on my last build and now all the gbuild agents fail on scm update. I was using an old continuum-1.1- SNAPSHOT but started running into this issue and changed it to continuum-1.0.2 for sanity sake, but still get the same issue. Seems to all be triggered by a NoClassDefFoundError for org/apache/ maven/artifact/versioning/InvalidVersionSpecificationException Not sure where this is coming from or why this isn't getting sucked in transitively. Any ideas? -David log-snippet 2006-01-16 21:27:29,143 [Thread-2] INFO ScmManager - Executing: svn --non-interactive update 2006-01-16 21:27:29,144 [Thread-2] INFO ScmManager - Working directory: /home/dblevins/ gbuild-agent-1.0-SNAPSHOT/bin/linux/../../apps/gbuild-agent/agent/ work/51 2006-01-16 21:27:30,100 [Thread-130] DEBUG ScmManager - At revision 1131. - this realm = plexus.application.gbuild-agent urls[0] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/maven-model-2.0.jar urls[1] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/maven-artifact-manager-2.0.jar urls[2] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/ognl-2.6.7.jar urls[3] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/continuum-store-1.0.2.jar urls[4] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/backport-util-concurrent-2.0_01_pd.jar urls[5] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/maven-settings-2.0.jar urls[6] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/commons-cli-1.0.jar urls[7] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/commons-pool-1.2.jar urls[8] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/jca-1.0.0.jar urls[9] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/maven-scm-api-1.0-beta-2.jar urls[10] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/plexus-velocity-1.1.2.jar urls[11] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/maven-artifact-2.0-alpha-2.jar urls[12] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/jpox-dbcp-1.1.0-beta-4.jar urls[13] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/doxia-sink-api-1.0-alpha-4.jar urls[14] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/maven-repository-metadata-2.0.jar urls[15] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/jaas-1.0.1.jar urls[16] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/commons-logging-api-1.0.4.jar urls[17] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/plexus-action-1.0-alpha-6.jar urls[18] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/continuum-api-1.0.2.jar urls[19] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/maven-scm-provider-svn-1.0-beta-2.jar urls[20] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/maven-plugin-parameter- documenter-2.0.jar urls[21] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/continuum-notifier-api-1.0.2.jar urls[22] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/commons-collections-2.0.jar urls[23] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/plexus-jdo2-1.0-alpha-3.jar urls[24] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/regexp-1.3.jar urls[25] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/jpox-1.1.0-beta-4.jar urls[26] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/concurrent-1.3.4.jar urls[27] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/maven-plugin-descriptor-2.0.jar urls[28] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/gbuild-agent-1.0-SNAPSHOT.jar urls[29] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/derby-10.1.1.0.jar urls[30] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/maven-reporting-api-2.0.jar urls[31] = file:/home/dblevins/gbuild-agent-1.0-SNAPSHOT/bin/ linux/../../apps/gbuild-agent/lib/maven-scm-provider-cvs-1.0-beta-1- SNAPSHOT.jar
[jira] Created: (MEV-299) Pom for activeio-2.1
Pom for activeio-2.1 Key: MEV-299 URL: http://jira.codehaus.org/browse/MEV-299 Project: Maven Evangelism Type: Improvement Components: Missing POM Reporter: David Blevins Made a valid pom for activeio-2.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MEV-299) Pom for activeio-2.1
[ http://jira.codehaus.org/browse/MEV-299?page=all ] David Blevins updated MEV-299: -- Attachment: activeio-2.1.pom.patch Pom for activeio-2.1 Key: MEV-299 URL: http://jira.codehaus.org/browse/MEV-299 Project: Maven Evangelism Type: Improvement Components: Missing POM Reporter: David Blevins Attachments: activeio-2.1.pom.patch Made a valid pom for activeio-2.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Security in Continuum
On Jan 11, 2006, at 10:13 AM, Emmanuel Venisse wrote: Hi, In 1.1, we have decided to rework all security features. I tried to use osuser but this framework is crappy : [...] I looked at seraph too. This project seems to be interesting, it's used by confluence and jira. It seems we have all we need in it but it require to be used in a web app environment, so i think we can't use it if we want to use security framework in a standalone app in future. Interesting, if you look at the dependencies for seraph, it's clearly using osuser. - http://opensource.atlassian.com/seraph/dependencies.html Wonder if writing our own option couldn't mean writing our own wrapper for osuser. -David
[jira] Created: (MEV-275) Castor dependencies
Castor dependencies --- Key: MEV-275 URL: http://jira.codehaus.org/browse/MEV-275 Project: Maven Evangelism Type: Improvement Components: Dependencies Reporter: David Blevins Added some of the missing deps for castor to run -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MEV-275) Castor dependencies
[ http://jira.codehaus.org/browse/MEV-275?page=all ] David Blevins updated MEV-275: -- Attachment: castor-1.0M1.patch Castor dependencies --- Key: MEV-275 URL: http://jira.codehaus.org/browse/MEV-275 Project: Maven Evangelism Type: Improvement Components: Dependencies Reporter: David Blevins Attachments: castor-1.0M1.patch Added some of the missing deps for castor to run -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Continuum refactoring
Just to jump in. I don't really see the limitation with the current ContinuumStore object. In fact, I would say the only real issue I see around it is that too many components are dependent upon it which makes Continuum somewhat database-centric. In most cases these components are just using it to pass parameters to each other in an indirect way and don't actually need to be updating or hitting the database over and over again. To my eyes, it seems that everything from the BuildController down doesn't actually need a store of any kind. So far it seems everything under that Component just needs the exact same instance of Project, BuidDefinition and BuildResult. All those objects could be wrapped into a new object BuildTask (or something similar) which could be a standard part of the context map sent into any build- related actions. Then several references to the ContinuumStore could be removed. There are some components below the BuildController that rely upon the ConfigurationService which needs the ContinuumStore to grab the SystemConfiguration object, but I would say maybe its a bit of a false assumption that the SystemConfiguration is stored in the same place where the Project and BuildDefinition information is stored. That is to say, if there is more than one system building the same set of projects (as in a distributed build system) the SystemConfiguration for each build agent will likely not be stored on the master build system serving as the definitive source of Project and BuildDefinition information. To summarize my thoughts: 1. One big ContinuumStore is fine as you are likely to have only one database and it makes it really clear what components are database-aware. Continuum doesn't have 50+ tables (data objects) so taking the EJB approach and having one DAO (EJBHome) per table is not really necessary. It gives you that nice organized feeling to have it broken up into small tiny pieces, but it doesn't help with maintenance as a change to the database is universal and affects everything. It also would make implementing a new store an arduous task. This part is purely anecdotal, so take it with a grain of salt, but those small DAO classes tend to fill up with application logic over time and eventually become irreplaceable. 2. Using the store to pass parameters is a no-no and needless dependence on the store is bad for components you may wish to reuse in a distributed system. -David On Dec 15, 2005, at 2:43 PM, John Casey wrote: While I do like the idea of splitting up any monolithic code in the DefaultContinuum class, I don't support splitting data-access code from itself. IMO, breaking data-access stuff by model-class is asking for trouble, since it doesn't allow a good mapping of data-access functions for managing relationships between multiple model classes. It think we can still gain a lot by separating the DAO stuff into a small number of DAO classes (maybe only one? definitely not one-per-model-class), and separating other bits of logic into coherent classes that are controlled by the DefaultContinuum class. For DAOs we need to avoid both the case where all DAO functions are stuffed in a single class Just Because - making it hard to maintain by sheer size - and the case where DAO functions dealing with object-object relations is shoved into a class where it doesn't make sense (i.e. on one of the classes' DAOs and not the other). -j Trygve Laugstøl wrote: On Wed, 2005-12-14 at 14:58 -0800, Carlos Sanchez wrote: On 12/14/05, Trygve Laugstøl [EMAIL PROTECTED] wrote: I still disagree with splitting up the ContinuumStore into a set of DAOs. I've never seen the advantage of having a single DAO for each domain object. They will be reusable in other applicaitons. If we're thinking about creting other applications, like repository manager, we'll share a lot of common objects between them. I have yet to see an example of this idea working in real life. I understand that you'd want to manage different sets of objects, but like in Continuum the Project and Build objects are to tightly coupled that you can't possibly store Project objects in one database and the Build objects in another. -- Trygve
Multiple Build Definitions
I'm still not sure how having multiple build definitions comes into play. I see now real way to use anything but the default. It's also a little confusing how the dont-execute-the-build-if-the- source-hasnt-changed-feature comes into play. They all have their own schedule and the source could get updated at anytime. Is it just a roll of the dice which build definition gets executed? Seems the first one to check would always be the one executed and the others with perhaps a less aggressive schedule would never get used. Or what happens if build definitions have the same schedule, which gets used then? Seems there is something useful there about having multiple build definitions, though I just can't see the vision with what has been implemented so far. -David
[jira] Created: (CONTINUUM-469) Allow build output to be downloaded as text
Allow build output to be downloaded as text --- Key: CONTINUUM-469 URL: http://jira.codehaus.org/browse/CONTINUUM-469 Project: Continuum Type: New Feature Components: continuum-core Versions: 1.1 Reporter: David Blevins Priority: Minor The geronimo build output is around 6 megs and little html text area with scroll bars is not the best way to search it and view it. It would be great to have a 'Download as text' link from the results page so that it would be possible to download the build output as text. Something like (just making it up): http://ci.gbuild.org/continuum/servlet/continuum/target/buildoutput/136.txt That would give me build output from buildId 136 Don't really care what the URL looks like aside from the fact that I want to be able to easily wget it so it should end in a decent file name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MEV-193) Patched activemq-core-3.2.pom
[ http://jira.codehaus.org/browse/MEV-193?page=all ] David Blevins reopened MEV-193: --- Patched activemq-core-3.2.pom - Key: MEV-193 URL: http://jira.codehaus.org/browse/MEV-193 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: David Blevins Assignee: Edwin Punzalan Attachments: activemq-core-3.2.pom.patch This pom has javacc-2.1 commented out as it doesn't exist yet in the maven repo. Also upgraded the derby version to 10.1.1.0 and fixed it's groupId to org.apache.derby -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MEV-193) Patched activemq-core-3.2.pom
[ http://jira.codehaus.org/browse/MEV-193?page=all ] David Blevins updated MEV-193: -- Attachment: activemq-core-3.2.pom.patch2 ActiveMQ core requires the concurrent library as it states on their website. Patched activemq-core-3.2.pom - Key: MEV-193 URL: http://jira.codehaus.org/browse/MEV-193 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: David Blevins Assignee: Edwin Punzalan Attachments: activemq-core-3.2.pom.patch, activemq-core-3.2.pom.patch2 This pom has javacc-2.1 commented out as it doesn't exist yet in the maven repo. Also upgraded the derby version to 10.1.1.0 and fixed it's groupId to org.apache.derby -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-193) Patched activemq-core-3.2.pom
[ http://jira.codehaus.org/browse/MEV-193?page=comments#action_50908 ] David Blevins commented on MEV-193: --- Here is the stacktrace you get without the concurrent jar. Comes from a test case that uses ActiveMQ java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/ConcurrentHashMap at org.activemq.broker.BrokerContext.init(BrokerContext.java:38) at org.activemq.broker.BrokerContext.clinit(BrokerContext.java:36) at org.activemq.broker.impl.BrokerContainerImpl.init(BrokerContainerImpl.java:96) at org.activemq.broker.impl.BrokerContainerImpl.init(BrokerContainerImpl.java:92) at org.activemq.broker.impl.Main.main(Main.java:44) Patched activemq-core-3.2.pom - Key: MEV-193 URL: http://jira.codehaus.org/browse/MEV-193 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: David Blevins Assignee: Edwin Punzalan Attachments: activemq-core-3.2.pom.patch, activemq-core-3.2.pom.patch2 This pom has javacc-2.1 commented out as it doesn't exist yet in the maven repo. Also upgraded the derby version to 10.1.1.0 and fixed it's groupId to org.apache.derby -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-439) Change scope on getType methods in AbstractContinuumAction
Change scope on getType methods in AbstractContinuumAction Key: CONTINUUM-439 URL: http://jira.codehaus.org/browse/CONTINUUM-439 Project: Continuum Type: Improvement Versions: 1.0 Reporter: David Blevins Priority: Minor I am subclassing AbstractContinuumAction in gbuild and need access to these methods. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-439) Change scope on getType methods in AbstractContinuumAction
[ http://jira.codehaus.org/browse/CONTINUUM-439?page=all ] David Blevins updated CONTINUUM-439: Attachment: AbstractContinuumAction.java.patch Change scope on getType methods in AbstractContinuumAction Key: CONTINUUM-439 URL: http://jira.codehaus.org/browse/CONTINUUM-439 Project: Continuum Type: Improvement Versions: 1.0 Reporter: David Blevins Priority: Minor Attachments: AbstractContinuumAction.java.patch I am subclassing AbstractContinuumAction in gbuild and need access to these methods. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-193) Patched activemq-core-3.2.pom
Patched activemq-core-3.2.pom - Key: MEV-193 URL: http://jira.codehaus.org/browse/MEV-193 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: David Blevins This pom has javacc-2.1 commented out as it doesn't exist yet in the maven repo. Also upgraded the derby version to 10.1.1.0 and fixed it's groupId to org.apache.derby -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MEV-193) Patched activemq-core-3.2.pom
[ http://jira.codehaus.org/browse/MEV-193?page=all ] David Blevins updated MEV-193: -- Attachment: activemq-core-3.2.pom.patch Patched activemq-core-3.2.pom - Key: MEV-193 URL: http://jira.codehaus.org/browse/MEV-193 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: David Blevins Attachments: activemq-core-3.2.pom.patch This pom has javacc-2.1 commented out as it doesn't exist yet in the maven repo. Also upgraded the derby version to 10.1.1.0 and fixed it's groupId to org.apache.derby -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CONTINUUM-416) A button I could click on the login page to remember me and automatically log me in next time
A button I could click on the login page to remember me and automatically log me in next time - Key: CONTINUUM-416 URL: http://jira.codehaus.org/browse/CONTINUUM-416 Project: Continuum Type: Wish Components: continuum-web Versions: 1.0 Reporter: David Blevins A button I could click on the login page to remember me and automatically log me in next time. Something similar to JIRA or Confluence. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-419) Can't click to see the latest build results from the main page
Can't click to see the latest build results from the main page -- Key: CONTINUUM-419 URL: http://jira.codehaus.org/browse/CONTINUUM-419 Project: Continuum Type: Improvement Components: continuum-web Versions: 1.0 Reporter: David Blevins Priority: Trivial When you are at the projects page (Summary.vm/fid/continuumProject) it's really annoying you can't just click somewhere and see the latest build results. You have to click Build History then the top results item, which is a big of traveling. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-420) Can't go directly to the Builds screen to view build history when at a results page
Can't go directly to the Builds screen to view build history when at a results page - Key: CONTINUUM-420 URL: http://jira.codehaus.org/browse/CONTINUUM-420 Project: Continuum Type: Improvement Components: continuum-web Versions: 1.0 Reporter: David Blevins Priority: Trivial It's really odd as the build results page takes over the 'Build' tab. It's fine if you clicked on the results link *from* the build history page, then you can just hit the browser back button (which is still mildly annoying). But if you clicked to the results page from a build email or something you are a few clever clicks away from getting that Builds tab to list the history again. You have to click on Info or Working Copy then click to return to the Builds tab which will now be the history page rather than the results you were looking at. Very strange. Consider a Results tab that could be a fourth tab on the top. Or a Build History link inside the results page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-419) Can't click to see the latest build results from the main page
[ http://jira.codehaus.org/browse/CONTINUUM-419?page=comments#action_49865 ] David Blevins commented on CONTINUUM-419: - Super. I'd want to use if for In progress builds too. Can't click to see the latest build results from the main page -- Key: CONTINUUM-419 URL: http://jira.codehaus.org/browse/CONTINUUM-419 Project: Continuum Type: Improvement Components: continuum-web Versions: 1.0 Reporter: David Blevins Priority: Trivial When you are at the projects page (Summary.vm/fid/continuumProject) it's really annoying you can't just click somewhere and see the latest build results. You have to click Build History then the top results item, which is a big of traveling. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-417) Don't list the entire revision history for a changed file, just the most recent changes
Don't list the entire revision history for a changed file, just the most recent changes --- Key: CONTINUUM-417 URL: http://jira.codehaus.org/browse/CONTINUUM-417 Project: Continuum Type: Improvement Components: continuum-web Versions: 1.0 Reporter: David Blevins Instead, think of allowing ViewCVS or FishEye to be configured and create links. It is *extremely* annoying the way it is now. On OpenEJB, when a project.xml file is changed, we get this: modules/core/project.xml djencks GERONIMO-1123 add dependencies on plugin where it is used djencks GERONIMO-1123 Use dependency plugin to generate geronimo-service.xml files djencks GERONIMO-880 Remove bouncy-castle in favor of some copied classes ammulderbranches: 1.58.2; Sync with Geronimo changes - ServerInfo now an interface - Moved management API interfaces to a new module djencks GERONIMO-784 and refactor xmlbeans2 plugin for move to xmlbeans djencks GERONIMO-782 step 1 remove xfire. Also clean up dependencies a bit dainRemoved openorb/tmporb Removed tools jar hack Removed all stub/tie compiler code since is used openorb djencks GERONIMO-738 move to xmlbeans v2 dainAdded KernelFactory for pluggable kernel Kernel is now an interface Moved Kernel implementation to basic kernel Converted JMX registry and config manager to plain old gbeans (they do not require special access to the kernel) Magic attributes such as state and enabled are now accessed via kernel methods Use of getAttribute and invoke for magic attributes and state transition is now deprecated Cleaned up cruft in GBean infos such as declaration of non existent attributes Upgraded to newest CGLIB, asm, and commons-collections djencks update dependency versions maguro Removed reliance on tmporb-ssl djencks Add NamedUsernamePasswordCredential and supporting infrastructure to allow configuring security info for ws client calls maguro Change dependency to geronimo-spec-corba. maguro Updated to use the default Sun ORB. dainConvert remaining tmporb references to openorb dainSwitch to tmporb chirino Implemented WSDL port address replacment. dblevinsFirst run of axis integration. more to sew up yet. maguro Intermediate CORBA checkin. djencks simple MEJB implementation, some changes to help MEJB deployment dblevinsRevising the WSContainer to better support rpc/encoded strictly against a lightweight WSDL-Java mapping. Added validation for lightweigth mappings. Added ability to download the WSDL via http://foobar.com/someservice?wsdl maguro Needed for CSIv2 djencks Partial implementation of GERONIMO-450. GBean names are (mostly) constructed like jsr-77 names and xml config usually only needs to specify namePart and optionally type chirino The geronimo security package now depends on activeio and no longer on geronimo remoting. dblevinsBasic soap rpc/encoded deployment and container support along with a general revamping of the networkservice stacks. dblevinsThe asm and bouncycastle dependencies had hardcoded versions dblevinsReformatted dainReplaced xml parsed entities for dependency version numbers with project.properties djencks GERONIMO-402, 464. Split openejb and security deployment code into separate modules djencks GERONIMO-403/405/418 Split builders out of j2ee, naming, and jetty maguro Intermediate CORBA checkin dblevinsUpdated castor version to 0.9.5.3 maguro CORBA jars djencks don't make duplicate xmlbeans-generated classes. Work around problem with xmlbeans imported group refs dblevinsAdded AppClient support for JNDI dainConsolidated all version numbers into etc/version-info.ent djencks Add timer support to session and mdbs. (entities still todo). Adapt to TransactionContextManager. Adapt to deploying with external plan. djencks Upgrade conncurrent to 1.3.4 djencks Implement message driven bean deployment and some of message-destination refs. Update to howl 0.1.3 dainUpdated the spec jar version numbers to rc2 djencks Eliminate two threadlocals. Move more thread specific context information (unshareableResources and applicationManagedSecurityResources) into the InstanceContext. dainUpdated deployment code to support new geronimo ear deployer dainChanged Geronimo version to 1.0-SNAPSHOT Changed OpenEJB version to 2.0-SNAPSHOT Changed TranQL version to 1.0-SNAPSHOT Changed Geronimo spec versions to match spec version with a -rc1 added dblevinsUpdated 2.0M1 to 2.0-M1 dainChanged tranql to version 1.0M1 dainChanged geronimo version to 1.0M1 dblevinsUpdated version number
[jira] Created: (CONTINUUM-409) Email notifications could still include build stats when includeBuildResult is false
Email notifications could still include build stats when includeBuildResult is false Key: CONTINUUM-409 URL: http://jira.codehaus.org/browse/CONTINUUM-409 Project: Continuum Type: Wish Versions: 1.0 Reporter: David Blevins I really like the Build statistics and Changes sections continuum creates in the emails and definitely want them in every email. It's really just the section that contains the output generated from the build itself that I don't want as that will consistently be several megs of text for our project. Basically, I assumed 'includeBuildResults=false' would just exclude out everything after these lines Output: I really don't care what the option is called as long as I can get an email as described. Maybe you want to do something like this includeBuildStatisticstrue/includeBuildStatistics includeChangestrue/includeChanges includeBuildOutputfalse/includeBuildOutput -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Build schedules
I have a hard time understanding what exactly build schedules are supposed to do affect. The default schedule is hourly, but this doesn't cause builds to be kicked off hourly. What is the deal here? -David
[jira] Created: (CONTINUUM-406) irc notifications: support for registered nicks
irc notifications: support for registered nicks --- Key: CONTINUUM-406 URL: http://jira.codehaus.org/browse/CONTINUUM-406 Project: Continuum Type: Improvement Versions: 1.0 Reporter: David Blevins Priority: Minor It seems IRC notifications don't work on irc.freenode.net. i assume it's due to them removing anonymous msg'ing. Probably need to set it up to use a registered nick, and do the /msg identify thing first -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-407) screen after adding/removing a build definition or notifier should be the project View page
screen after adding/removing a build definition or notifier should be the project View page --- Key: CONTINUUM-407 URL: http://jira.codehaus.org/browse/CONTINUUM-407 Project: Continuum Type: Improvement Components: continuum-web Versions: 1.0 Reporter: David Blevins screen after DeleteNotifier, AddNotifier and similar actions of the project View page should return you to the project view page, not the list of all projects. it takes entirely too long to administer a project if you have to keep clicking back to the project you are updating. If you need to make more than one change, it's a complete pain. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
