Re: svn commit: r546588 - in /maven/continuum/trunk: ./ continuum-data-management/data-management-cli/src/main/java/org/apache/maven/continuum/management/ continuum-data-management/data-management-jdo
On 12 Jun 07, at 11:37 AM 12 Jun 07, [EMAIL PROTECTED] wrote: Author: brett Date: Tue Jun 12 11:37:19 2007 New Revision: 546588 URL: http://svn.apache.org/viewvc?view=rev&rev=546588 Log: other aspect of CORE-3297 requires a patch to OID instead This the CORE I know? Thanks, Jason ------ Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com --
Re: Poll: release continuum alpha
On 24 Feb 07, at 5:08 PM 24 Feb 07, Jesse McConnell wrote: ideally we will revisit a couple of fundamentals for this release still like build profiles, so yes, a couple of planned new features, hopefully assisted by a new person or two interested I would chop the new features pretty close to now and start churning out the alphas as quickly as possible. Get feedback, alter APIs where absolutely necessary, send it out until the API stabilizes and then release it. I would say stuff you're not sure about or needs a lot of work, take that code and spin it out into a feature branch so the rest can stabilize. I would say do whatever is necessary to release something stable in a couple weeks. Jason. jesse On 2/24/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote: if we are not planning to add new features and just bugfixes then I understand it's a beta On 2/24/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > On 24 Feb 07, at 1:05 PM 24 Feb 07, Carlos Sanchez wrote: > > > +1 for a beta, if everything it's cool let's go for 1.1 and push to > > -1 for beta > > This version has so many changes it cannot be called a beta until it > has been tried en masse. It is most certainly an alpha. > > Jason. > > > 1.1.1 whatever else that needs to be fixed > > > > On 2/23/07, Jesse McConnell <[EMAIL PROTECTED]> wrote: > >> I was talking to trygve a bit on irc and it dovetailed nicely with > >> some plans I had talked about late last year in regard to > >> continuum...I am just about a month late is all. We thought we ought > >> to take a poll on here about continuum and see what folks thought. > >> This is not a vote, its just a poll and perhaps a discussion starter > >> on short to mid term plans with continuum. I just know it bothers me > >> a bit everytime someone pops on IRC and asks questions about > >> continuum > >> 1.0.3...which is quite aged atm with so many of the bugs on it > >> resolved on the trunk. > >> > >> > >> > >> > >> Question: Should we take all the work that has been done on > >> continuum > >> in the last year+ and get it pushed out as an Alpha1 or a Milestone1 > >> or some suitable equivalent? > >> > >> [+1/0/-1] > >> > >> > >> jesse > >> > >> > >> > >> -- > >> jesse mcconnell > >> [EMAIL PROTECTED] > >> > > > > > > -- > > I could give you my word as a Spaniard. > > No good. I've known too many Spaniards. > > -- The Princess Bride > > > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride -- jesse mcconnell [EMAIL PROTECTED]
Re: Poll: release continuum alpha
On 24 Feb 07, at 1:05 PM 24 Feb 07, Carlos Sanchez wrote: +1 for a beta, if everything it's cool let's go for 1.1 and push to -1 for beta This version has so many changes it cannot be called a beta until it has been tried en masse. It is most certainly an alpha. Jason. 1.1.1 whatever else that needs to be fixed On 2/23/07, Jesse McConnell <[EMAIL PROTECTED]> wrote: I was talking to trygve a bit on irc and it dovetailed nicely with some plans I had talked about late last year in regard to continuum...I am just about a month late is all. We thought we ought to take a poll on here about continuum and see what folks thought. This is not a vote, its just a poll and perhaps a discussion starter on short to mid term plans with continuum. I just know it bothers me a bit everytime someone pops on IRC and asks questions about continuum 1.0.3...which is quite aged atm with so many of the bugs on it resolved on the trunk. Question: Should we take all the work that has been done on continuum in the last year+ and get it pushed out as an Alpha1 or a Milestone1 or some suitable equivalent? [+1/0/-1] jesse -- jesse mcconnell [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Poll: release continuum alpha
+1 For an alpha-1, you can't call it anything else until you push it out and get feedback. It's getting close to a year the codebase is quite different and it's like releasing something new. But I think the group owes it to users to get this thing out. Continuum deserves the garner the same criticism Maven did for taking 10 months to come up with another release. The release will motivate everyone again. Call it an alpha, send it out, get the feedback and carry on. I think it's more harmful not releasing at this point. It's simply been too long. Jason. On 23 Feb 07, at 4:35 PM 23 Feb 07, Jesse McConnell wrote: I was talking to trygve a bit on irc and it dovetailed nicely with some plans I had talked about late last year in regard to continuum...I am just about a month late is all. We thought we ought to take a poll on here about continuum and see what folks thought. This is not a vote, its just a poll and perhaps a discussion starter on short to mid term plans with continuum. I just know it bothers me a bit everytime someone pops on IRC and asks questions about continuum 1.0.3...which is quite aged atm with so many of the bugs on it resolved on the trunk. Question: Should we take all the work that has been done on continuum in the last year+ and get it pushed out as an Alpha1 or a Milestone1 or some suitable equivalent? [+1/0/-1] jesse -- jesse mcconnell [EMAIL PROTECTED]
Re: [discuss] iBatis, JPA and Java 5.0
On 2 Jan 07, at 10:59 PM 2 Jan 07, Brett Porter wrote: I've been thinking stay with JDO for now, look at JPA in the long term. I think anyone who wanted to look at an iBatis store I say go for it. JDO is not bad, but JPOX has proven to be less then robust. If we were using Kodo it would be a different story and it's too bad that BEA did not release the JDO bindings for the JPA stuff. I would also say try another tool like a JDBM store so that you get the magic three. If the store API was fleshed out and worked with three backend implementations you would have something that works. I think part of the problem is that we've let JDO shape the store API instead of arriving at an ideal API. I think this can only be accomplished by attempting to use another back end store. If Rahul wants to try iBatis I say let it rip. Jason.
Re: Are passwords required?
On 26 Dec 06, at 10:58 AM 26 Dec 06, Jesse McConnell wrote: imo, yes :) only the administrator has the ability to make those decisions and they ought to be allowed to do it... Definitely, as it might be used in a small group, in an already secure environment. Assume the driver has a brain. Jason. we restrict it already that users are not by default allowed to make empty passwords but with a but of configuration they should be allowed to not have passwords, if that is the admin's desire. also, admins can make passwords that don't follow the password conventions, but by default they are setup to be forced to make a password that does conform on first login jesse On 12/26/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: In 1.1-SNAPSHOT, on 'Create New User', I can create an account with no password, even though the two password fields have asterisks displayed next to them. If I then edit the user and uncheck the 'Change Password Next Login' box, the user can log in without a password. Should this be possible? -- Wendy -- jesse mcconnell [EMAIL PROTECTED]
Re: short term branch for project/group keys
On 22 Dec 06, at 10:33 PM 22 Dec 06, Christian Edward Gruber wrote: If we use JPA or some such with caching at the HttpSession-scoped level for keys (with some fancy dealing, I admit) we can have each person's view independent on a per-session basis. That is, the key will be translated into an id _in that person's context_, and the real id's are used to fetch. So a key change will only affect them when their keys refresh. Now we need a strategy for refresh, but hey... one problem at a time. :) Yah, you can't think of any specific persistence store here as the store api should work with any persistence mechanism. Jason. Not the best idea I've had, but more to point out that there are some solutions to this that can be fairly simple in practice. Christian Rahul Thakur wrote: [snip] the project.id and projectGroup.id will basically disappear from continuum, reserved strictly for the underlying store. The store can do whatever it wants with them. Ok, so a project(Group)? will have: id : int key : String name : String ... Where key is used as a reference, id is used as a datastore/model identity, and name is used as a display. Sounds good. We could then have a table of "old names": id : int oldKey : String These could be used so that failed lookup on a key could then look in the old key's to find out what the new one is (like when you move an issue in JIRA). I'm not sure this is needed initially - only if we support picking up renames to the project itself. [/snip] That was my point in my last email. I understand why we need that "old key" table but this would be something that will just get bloated over time. There could be a 'housekeeper' process that can clean up old keys after a certain time has expired. I don't see a reason why we need to keep the old stuff for long. Cheers, Rahul -- *christian** gruber + process coach and architect* *Israfil Consulting Services Corporation* *email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*
Re: short term branch for project/group keys
On 22 Dec 06, at 11:48 AM 22 Dec 06, Jesse McConnell wrote: nope, no fundamental reasons behind the immutable bit on the keys, I am cool with them being open for editing. I think they are immutable so when links are created with them they don't just disappear. Jason. jesse On 12/22/06, Christian Edward Gruber <[EMAIL PROTECTED]> wrote: This all sounds great, but why do they need to be immutable? If they are essentially used for lookups, and they only exist in one place in the database (because it's normalized enough through surrogate keys), then other then the obvious caveats about external things depending on the keys, why couldn't these string keys change? There should be no referential integrity issues, because these keys are not the subjects of any joins - just where clauses from the interfaces. This would include project.key, group.key, buildDef.key, notifier.key, etc. It could even apply to userId, though standard practice is that usernames are immutable. All the other "lookup keys" could quite easily be mutable/re-nameable if we wished. Am I missing something? I can certainly see the usefulness of being able to, for maintenance of the continuum instance. Not strictly necessary, but saves several steps. Christian. Jesse McConnell wrote: > On 12/22/06, Brett Porter <[EMAIL PROTECTED]> wrote: >> Sounds good, as long as the store remains independent of them. I >> don't want to get into the situation like in JIRA where you can't >> rename a string key. > > Yes, jason pinged me on this since I guess I wasn't completely clear > in that summary. > > the project.id and projectGroup.id will basically disappear from > continuum, reserved strictly for the underlying store. The store can > do whatever it wants with them. The UI will never pass around a > projectId=26 param on a url making you wonder what the heck it was. A > nice side effect of this IMO is that the #'s in the working directory > would go away as well, defaulting instead to a nested directory > structure of workingDirectory/GroupKey/ProjectKey/pom.xml > > Now I had honestly been thinking of making the key's immutable, since > the names of the group's and project's are to be used for all > presentational type things. I was going to treat keys under the same > functional requirements that usernames generally have. Maybe we offer > a 'Clone' option that makes a deep copy of the data in the DB into a > new name and then allow the deletion of the old one... > > Anyway, here are the restrictions I thought of placing on the keys. > > * [a-zA-Z1-9.-:] for all keys > * group key is unique > * group key + project key is unique > * project key should _not_ need to be unique (ex Doxia/Core + > Maven/Core + Continuum/Core) > * keys are immutable, set upon creation > >> Before starting to hack on this, perhaps you could list out all the >> keys you think are needed, and some examples? I'm interested in how >> it relates to group IDs and artifact IDs in particular. > > Initially I was planning on doing just the project key and group key > since there is so much involved with getting just those two in place. > However everything would probably go that way so that Profiles, > Schedules, BuildDefinitions, etc...anything with an int ID that is > used around in continuum would be converted to use a strongly typed > string key insteadthe ones other then project and group are less > important in the short term since they are not a constant source of > confusion...but eventually yes anything with and ID would get a Key > like this. If the branch is a success and is voted back onto trunk > then those could take place on trunk I think since they are smaller > scope. > > As for how they would relate to groupId's and artifactId's it was not > my intent to deal with those at all. One of the things that got us > into the mess that currently exists was too great a focus on the m2 > side of continuum. IMO the group and project keys should be kept > external to any concept of project type. That way we can always > maintain a clear delineation between a group and its member projects > in relation to other groups. For instance, one of my goals here is to > make it super easy to have multiple versions of Doxia load up in > continuum and execute in their little sandboxes. > Group Keys of Doxia and Doxia-Refactor (just an example branch) should > be able to seamlessly import the doxia project from its relative > sources and peacefully coexist. And it should be just as easy to do > the same with a number of ant, shell and maven1 projects. > > Anyway, some foreseeable real world example keys in one continuum > instance: > > Group: > Maven-Trunk > Projects: > Core > Api > Artfiact > > Group: > Maven-2.0.5 > Projects: > Core > Api > Artifact > > Group: > Continuum > Projects: > Core > Api > Store > Webapp > > cheers, > > jesse > > >> - Brett >> >> On 22/12/2006, at 6:30 AM,
Re: Updating JIRA
On 9 Dec 06, at 11:58 AM 9 Dec 06, Jesse McConnell wrote: By that logic then I think alpha is definitely what we could start pulling off now and then with some milestones. I know I really want to get the shortcuts bit that I been promoting on another thread in place and that is some more api changes...for the better too since I really want to see the api's from top to bottom working off of things like projectKeys and groupKeys instead of jpox id's and freeform string names of things. I am actually hoping to spend some of my vacation over xmas working on getting that into place. continuum 1.0.3 has been out for a while now and there have been a lot of tangible improvements that we should get into peoples hands in the form of the alpha releases. I figured with labeling of alpha we can freely change the model if we need to and not worry about migrating peoples old databases, though that might be good practice to get into place... Exactly, you can't rope everyone into using something by labeling it a beta and then find out you really require and model/API change. You'll probably get fewer people trying out and alpha but I think think enough to help shape things toward what they need to be. so what do others think? shall I make an 1.1-alpha-1 version in the jira and we can get the issues that we want to have really resolved for that in place? Target January for a 1.1-alpha-1 release and then every month after that until we are feature complete and start doing a beta or two...? Sounds good. I would like to see 1.1 out as fast as possible too but you need to get some feedback. Jason. jesse On 12/9/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: On 9 Dec 06, at 11:37 AM 9 Dec 06, Jesse McConnell wrote: > right, last time I brought this up the goal was to resolve all those > for an actual 1.1 release.. > If that's the case that's cool. > I would like to see maybe an alpha-1 release in January perhaps > followed up a beta or two once all the confirmed new features are in > place (like profiles, etc). > I think what is critical and what is not being done is being honest about over stability of the product and of the API. Provided the API is know to be stable and the stability of the tool itself is good then a beta is fine to release. We're labeling stuff like Archiva as beta and it's not even close which I can attest to with having to try and keep it up on central for the last month. This stuff cannot go out as beta in alpha form. People will consume releases, we just have to be honest about it. > I think the decision had not be to actually break out something like > alpha and beta releases into jira but for sanities sake perhaps we > could reevaluate that. > I think the EAP stuff is fine and that could be considered the alphas but I think people like the markers. So EAPs can go out weekly, I think that's a good thing but even folks like Intellij releases betas. I think they just do the EAP thing for marketing so that it doesn't actually say alpha when it really is. > I know I went through about a month ago and poked through most of the > issues making sure they were in the right components at least...but I > think actually breaking down further into achievable shorter term > goals would be a good thing. I think so. I mean it will be April before those 163 issues get resolved. Jason. > > jesse > > On 12/9/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: >> Hi, >> >> If anything is thinking of doing a release of Continuum anytime soon >> can you please update Continuum's JIRA so that it's representative of >> what's going to be fixed for at least the next release like Kenney >> and I have done for Maven itself: >> >> http://jira.codehaus.org/browse/MNG >> >> I don't think you're doing to be fixing 163 issues for Continuum 1.1. >> >> Thanks, >> >> Jason. >> >> >> > > > -- > jesse mcconnell > [EMAIL PROTECTED] > -- jesse mcconnell [EMAIL PROTECTED]
Re: svn commit: r479498 - in /maven/continuum/trunk: ./ continuum-cc/ continuum-distributed/ continuum-sandbox/continuum-cc/ continuum-sandbox/continuum-distributed/ continuum-sandbox/continuum-update
On 27 Nov 06, at 3:48 AM 27 Nov 06, Emmanuel Venisse wrote: It's isn't an old module but a not used module, so it should be in sandbox. That's not true, but as I told Brett I will work sync my stuff back into the sandbox and integrate it later. Jason. Emmanuel Jason van Zyl a écrit : continuum-distributed is not an old module, please put that one back. Jason. On 26 Nov 06, at 9:54 PM 26 Nov 06, [EMAIL PROTECTED] wrote: Author: brett Date: Sun Nov 26 18:54:54 2006 New Revision: 479498 URL: http://svn.apache.org/viewvc?view=rev&rev=479498 Log: move old modules to the sandbox Added: maven/continuum/trunk/continuum-sandbox/continuum-cc/ - copied from r479496, maven/continuum/trunk/continuum-cc/ maven/continuum/trunk/continuum-sandbox/continuum-distributed/ - copied from r479496, maven/continuum/trunk/continuum- distributed/ maven/continuum/trunk/continuum-sandbox/continuum-updater/ - copied from r479496, maven/continuum/trunk/continuum- updater/ maven/continuum/trunk/continuum-sandbox/continuum-xfire/ - copied from r479496, maven/continuum/trunk/continuum-xfire/ Removed: maven/continuum/trunk/continuum-cc/ maven/continuum/trunk/continuum-distributed/ maven/continuum/trunk/continuum-updater/ maven/continuum/trunk/continuum-xfire/ Modified: maven/continuum/trunk/pom.xml Modified: maven/continuum/trunk/pom.xml URL: http://svn.apache.org/viewvc/maven/continuum/trunk/pom.xml? view=diff&rev=479498&r1=479497&r2=479498 == --- maven/continuum/trunk/pom.xml (original) +++ maven/continuum/trunk/pom.xml Sun Nov 26 18:54:54 2006 @@ -82,7 +82,6 @@ continuum-api continuum-security -continuum-cc continuum-core continuum-model @@ -92,7 +91,6 @@ continuum-rpc-client continuum-store continuum-test - continuum-webapp continuum-xmlrpc continuum-release
Re: svn commit: r474987 - in /maven/continuum/trunk/continuum-core: ./ src/main/java/org/apache/maven/continuum/ src/main/java/org/apache/maven/continuum/build/settings/ src/main/java/org/apache/maven
On 14 Nov 06, at 4:22 PM 14 Nov 06, [EMAIL PROTECTED] wrote: Author: jmcconnell Date: Tue Nov 14 13:21:59 2006 New Revision: 474987 URL: http://svn.apache.org/viewvc?view=rev&rev=474987 Log: continuum-758 converted continuum-core over to use the plexus-maven- plugin where it can in generation of the components.xml and then a merge with the components can can't be totally configured that way. This tore a lot of the meat out of the existing components.xml and should make working with the settings we need to manage with it a lot easier. I commented where the components that are in continuum-core that couldn't be configured with the plugin in the components.xml file that we are merging in. Nice! Jason.
Re: [discuss] Writing WebWork actions
On 25 Oct 06, at 4:05 PM 25 Oct 06, Jesse McConnell wrote:
that actually segways nicely into a topic brett brought up a long time
back where it would be really nice to not even write the majority of
actions, but to just annotate them somewhere and have a plugin like
the cdc just generate the webwork actions themselves.. I was actually
kicking that around a bit yesterday.
You need actions, but they are application actions. What Summit
attempted to allow was for you to write your application actions
regardless of the view. Then in a declarative way the parameters you
wanted from the webview were extracted and directed to the
application action. I never documented Summit and it did Velocity so
I wasn't going to foist in on everyone but I still maintain it is
possible to purely have configuration for moving parameters from a
view to the application for execution. Internationalization,
exception handling and reporting are important and I went down the
wrong path there in Summit but I would say shoot for not writing
Webwork actions at all. The plexus-action component is currently
inappropriate but I am still for writing all the actions as simple
objects with the idea of creating activities and workflows.
You simply need a mapping mechanism you move things from the webview.
I used OGNL expression in Summit to extract the information but
something fast could be used. You can't annotate the actions because
they may be used by different views where the person writing the only
really needs to know what to send to the action so you can't mix
those concerns. So for a single page, or multi-page diaglog with a
web user you collect all the relevant information extracting the
parameters you need from each request/response and then pass that all
along to the application. The webwork actions should do absolutely
zero application logic. I know most actions just grab some
information and then call the application but app logic always creeps
in which is bad because it means that using a web services interface
I'm going to get different behavior. I definitely think eliminating
the WW action usage would be a good thing and turn purely into an
information mapping layer. My attempt failed with Summit but I know
it's possible.
Something like:
public interface Action
{
ActionResult execute( Map parameters )
throws ActionExecutionException;
}
Would mostly do the trick as from any view the parameters can always
come in a Map and you can do efficient things like create Map
adapters so you can use request parameters directly without having to
push them all into a Map. When the action executes you can always
clearly see the result so this works manually nicely, and if you tie
this up into a workflow the engine can inspect the action results
along the path of execution to control the flow of the activity.
Create a good application interface with a rich model and then create
a layer to extract the information from the view to used in the
execution of an application action, actions, or activity.
Jason.
good points, all of them.
one thing that I don't like about the combined into one object is you
end up having a score of unused fields for operations like delete.
anyone else?
jesse
On 10/25/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 25 Oct 06, at 3:46 PM 25 Oct 06, Jesse McConnell wrote:
> I also bounced this off of a couple other people over the last day
> or to..
>
> there seems to be a general consensus from folks that I talked
to that
> its a good idea to try and group all the CRUD (Create, Read,
Update,
> Delete) actions on objects grouped into a single action.
>
Why? I think that's a bad idea. An action in the traditional sense is
atomic and are strung together to create activities. I think jamming
these things together is bad. I think jamming fundamentally different
actions together is bad. We used to do this in Turbine where one Java
class could perform any number of actions and it was a maintenance
nightmare.
With individual actions classes it will always pertain to that action
and it can be modified without having to worry about side effects. If
the class is doing more then one thing it's not really an action
anymore.
Are you only talking about webwork actions here? For me I've always
wanted a declarative way to map the web junk to the real actions of
the application. And if I were to wire together a series of actions
into a activity using a workflow tool I would definitely never put
the logic of more then one action into one class. Having the logic
contained in a single class means that you can always operate on the
class in a very known way. As soon as you have something more then
that you entirely lose the power of abstraction. Does it do one
thing? Does it do two things? Do I need to create a method to tell me
what it
Re: [discuss] Writing WebWork actions
On 25 Oct 06, at 3:46 PM 25 Oct 06, Jesse McConnell wrote:
I also bounced this off of a couple other people over the last day
or to..
there seems to be a general consensus from folks that I talked to that
its a good idea to try and group all the CRUD (Create, Read, Update,
Delete) actions on objects grouped into a single action.
Why? I think that's a bad idea. An action in the traditional sense is
atomic and are strung together to create activities. I think jamming
these things together is bad. I think jamming fundamentally different
actions together is bad. We used to do this in Turbine where one Java
class could perform any number of actions and it was a maintenance
nightmare.
With individual actions classes it will always pertain to that action
and it can be modified without having to worry about side effects. If
the class is doing more then one thing it's not really an action
anymore.
Are you only talking about webwork actions here? For me I've always
wanted a declarative way to map the web junk to the real actions of
the application. And if I were to wire together a series of actions
into a activity using a workflow tool I would definitely never put
the logic of more then one action into one class. Having the logic
contained in a single class means that you can always operate on the
class in a very known way. As soon as you have something more then
that you entirely lose the power of abstraction. Does it do one
thing? Does it do two things? Do I need to create a method to tell me
what it does so I can generalize it? All bad things. It does one
thing, only one thing and will always only do one thing.
On that note, it would be good to standardize the method names as
well, perhaps to:
public String add() {}
public String update() {}
public String view() {}
public String remove() {}
Then we would have the decision of the xwork.xml which could have
actions for each of these methods on the class, like
or on the jsp's we could just use the shortcut of action="foo!add">
how does this grab folks? I think this is a valuable step in things
since it will give us a chance to audit all of the actions, improve
the -webapp project for contributors...and -webapp is a great place
for people to start with continuum...and it will also serve as a good
swift kick towards finishing off the testing work that emmanuel will
be committing soon.
jesse
On 10/25/06, Rahul Thakur <[EMAIL PROTECTED]> wrote:
Jesse and I tossed some ideas about having some sort of consistent
patterns for writing Webwork actions in Continuum. Below is a
transcript
from yesterday's chat. We wanted to bring this up for discussion and
would be great to have any ideas/suggestions other might have.
Cheers,
Rahul
hello there
heya
just had some ideas that I wanted to jot down here quickly
shoot
ok, here goes (and pls bear with me if I have to go check on
breakfast :) )
ok, i have quick run thru of the patterns/conventions that we
are using in our internal framework
starting with xwork.xml , the equivalent config.xml is
broken up
into 3 files
1) defines components - lets call it components.xml
2) defines pages (that are composite of layout templates +
components) , lets call it pages.xml
3) defanes action patch mappings (page flow) - lets call it
mappings.xml
1) follows convention that all component names are
prefixed with
'component.' - ex: 'component.group.notifier.edit'
2) has page names prefixed with 'page.' - ex:
'page.notifier.summary'
action mappings are pretty much similar to what is there in
xwork.xml currently - i will come to method name later
i am just rattling off here with notes :) - you will have to
help me see these elements can/do map to WW or can be made to map
Components are supported by component handlers - that prepare
the display of and help render components - The java classes are
suffixed XXXComponentHandler. I have come across this with notifiers
Action classes are ManageAction - that process requests
for - edit/update/delete. I think the create one is different (I will
have to check again)
methods in ManageXXXAction follow convention (like I
mentioned) - processEditRequest, processUpdateRequest,
processDeleteRequest
and validations are performed in the actions themselves
(but I
like what WW does from validation.xmls)
for 'result' returned from the action - 'success' and
'failure'
are by default available and another convention is
'failure.system' for
any internal errors
other results can map to the action request -
'success.edit' ,
'success.delete' - I am adding this from my end :)
so, what do you reckon?
sorry i haven't been able to put it in an email yet
reading latest
I have actually been kicking around something brett
mentioned a
while back about generating actions automatically for CRUD things
and I talked to patrick lightbody and he was a fan of all
CRUD
operations being in one object
which was w
Re: contents of a 1.1 release
On 17 Oct 06, at 6:15 PM 17 Oct 06, Jesse McConnell wrote: well, I am working on finishing up some lingering project group functionality now, but once I knock it off my list I'll work on the testing some. I'll need to get up to speed on the latest integration testing work you have been working on jason, and emm mentioned on irc a while back that he was going to take a stab at bringing the web testing back on line so I'll ping him and work with him on that... I think the path of separating out ITs into a separate project is the way to go. So they are a separate project and become the gold standard. Many versions of Maven can be run against the Maven ITs, and the same would be useful for Continuum. also, its looks like there is a bit of a split on where to go release wise atm, but I think we can all generally acknowledge that the tests need to get improved, at the very least getting the web testing back where it was before the ui refactor to webwork. Perhaps we should shoot for a feature freeze of sorts for the middle of november and check where we are for a 1.1 release around that time. A month should be more then enough time to get the test case positions recovered to an acceptable lvl and get a mess of the outstanding issues resolved/lacking features fixed up. If the test are heading in the right direction that's cool and in a month they should be healthy as that's a good chunk of time. But the automated testing is key. Jason. jesse On 10/17/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: On 17 Oct 06, at 2:34 PM 17 Oct 06, Brett Porter wrote: > I agree with Emmanuel. IIRC, the profiles are already in the model, > and basic choice of which JDK and maven/ant installation to use > should be straightforward and extremely useful. I agree that making > it more pervasive and using the toolchain support would be even > better, but I don't believe it needs to wait for that. > I would be against any more radical changes until the testing setup is rock solid. We're slipping in this area. We don't really know what machines this stuff runs on and I don't think anything is automated anymore. We need to stop paying lip service to what we are preaching. Jason. > - Brett > > On 18/10/2006, at 12:54 AM, Emmanuel Venisse wrote: > >> The introduction of continuum profiles isn't impacted by the >> DefaultContinuum refactoring. >> If we don't provide a full continuum profiles implementation in >> 1.1, I think we can do a minimal one with only the possibility to >> choose the maven1/maven2/ant/java home directories and use them >> instead of using maven/ant/mvn/java from the PATH. This feature >> isn't big to do. >> >> In 1.1, I'd like to see the possibility to choose in build >> definitions if a project is built with an update (like it's done >> actually) or with a clean checkout. >> >> The last point, I'd like to see in 1.1 is the dependency/parent >> change build-trigger. >> >> All these features are awaited by users since a long time. I don't >> think the implementation will take lot of time, so they can be add >> in 1.1. >> >> Of course, we need a database migration tool for the release too. >> >> Emmanuel >> >> Jesse McConnell a écrit : >>> I was going to try and wrap my head about what needed to get wrapped >>> up for a 1.1 release of continuum this week when I got to talking to >>> emmanuel this morning. >>> I had been under the impression that we were getting near a point >>> that >>> we might want to polish things up and cut a 1.1 release but emm was >>> thinking that we ought to have another big push for new features >>> before we start polishing things up. So I told him I would mention >>> our talk and see what kinda interest we got from people on new >>> features and who might want to tackle what in the short term, or >>> if we >>> wanted to put some things out into the longer term bin. >>> One of the major things that I had been thinking we would push >>> off to >>> the 1.2 release was the profiles. Its a slightly overridden term as >>> it has little to do with maven profiles, but in my mind at least the >>> profiles were going to be 1/3 of a trinity by which builds could be >>> setup to run. >>> The trinity being: profile (maven instance, env vars, maven >>> profiles, >>> jdk instance, etc), temporal ( scheduled cron, when dependency >>> changes, scm activity, etc) and the project group (bundle of >>> projects). I was figuring that those three things taken together >>> ought meet the requi
Re: contents of a 1.1 release
On 17 Oct 06, at 2:34 PM 17 Oct 06, Brett Porter wrote: I agree with Emmanuel. IIRC, the profiles are already in the model, and basic choice of which JDK and maven/ant installation to use should be straightforward and extremely useful. I agree that making it more pervasive and using the toolchain support would be even better, but I don't believe it needs to wait for that. I would be against any more radical changes until the testing setup is rock solid. We're slipping in this area. We don't really know what machines this stuff runs on and I don't think anything is automated anymore. We need to stop paying lip service to what we are preaching. Jason. - Brett On 18/10/2006, at 12:54 AM, Emmanuel Venisse wrote: The introduction of continuum profiles isn't impacted by the DefaultContinuum refactoring. If we don't provide a full continuum profiles implementation in 1.1, I think we can do a minimal one with only the possibility to choose the maven1/maven2/ant/java home directories and use them instead of using maven/ant/mvn/java from the PATH. This feature isn't big to do. In 1.1, I'd like to see the possibility to choose in build definitions if a project is built with an update (like it's done actually) or with a clean checkout. The last point, I'd like to see in 1.1 is the dependency/parent change build-trigger. All these features are awaited by users since a long time. I don't think the implementation will take lot of time, so they can be add in 1.1. Of course, we need a database migration tool for the release too. Emmanuel Jesse McConnell a écrit : I was going to try and wrap my head about what needed to get wrapped up for a 1.1 release of continuum this week when I got to talking to emmanuel this morning. I had been under the impression that we were getting near a point that we might want to polish things up and cut a 1.1 release but emm was thinking that we ought to have another big push for new features before we start polishing things up. So I told him I would mention our talk and see what kinda interest we got from people on new features and who might want to tackle what in the short term, or if we wanted to put some things out into the longer term bin. One of the major things that I had been thinking we would push off to the 1.2 release was the profiles. Its a slightly overridden term as it has little to do with maven profiles, but in my mind at least the profiles were going to be 1/3 of a trinity by which builds could be setup to run. The trinity being: profile (maven instance, env vars, maven profiles, jdk instance, etc), temporal ( scheduled cron, when dependency changes, scm activity, etc) and the project group (bundle of projects). I was figuring that those three things taken together ought meet the requirements for building what, where and when. It would be a matter of setting up the permutations of those three components, for example: 2 profiles, 1 schedule, 1 project group would make 2 instances of schedulable FOO. Anyway, I digress...profiles would be one large feature that would be wonderful to have in continuum, sooner the better. But it would be pretty massive effects on the codebase. So massive that I would think we ought to consider splitting up the DefaultContinuum object into the workflows that have been kicked around, making things like 'Add Project To Project Group' extensible by users so they can trigger any other processes they might want running on those events. Trygve has some definite ideas in this area, perhaps using the plexus-spe code. The actions in continuum have been a first pass attempt at starting to break things out of the DC object which is pretty big atm. If we were going to rip the top off of the DefaultContinuum object and add/modify in the profile concepts into the store then we really ought to clean up the whole store api which is more painful to work with then it really should be. joakim and I had a lot of success with structuring things nicely in the plexus-security jdo stores and we could probably apply a ton of the concepts there in terms of api to the continuum-store and make it scads easier to work with. and on and on. I agree with Emmanuel that since 1.1 as it currently stands is not backwards compatible (I think) with the old database we ought to just add in what we need now...But doing this will definitely move out a 1.1 release into the new year...and is that something we want to do? I dunno really, personally I would be cool with adding in profiles and refactoring the core chunks of continuum up now and get it over with, but does anyone else have anything to say on the matter? I know we have had a lot more interest recently by folks like rahul and christian on participating, would you guys be interested in taking on some of these challenges with us? Theres nothing like ripping through the guts of code to really get involved :) thoughts? sh
Re: [vote] rbac-integration branch merge to trunk
On 6 Oct 06, at 11:42 AM 6 Oct 06, Jesse McConnell wrote: summary: +1 - 8 binding would be 5 I think.. 3 is all you need with no -1s. So I'll get this merged over in the next couple of days, probably early next week actually, there are some jsp integration issues that will have to take place from what I have heard. but we'll integrate this over to trunk asap, jesse On 10/4/06, Trygve Laugstøl <[EMAIL PROTECTED]> wrote: Jesse McConnell wrote: > Brett suggested we do a vote for this today so I figured I would just > do that now. > > [-1/0/+1] vote will be open for 72 hours +1 -- Trygve -- jesse mcconnell [EMAIL PROTECTED]
Re: rbac-integration continuum branch
On 28 Sep 06, at 9:28 AM 28 Sep 06, Carlos Sanchez wrote: is it using maven-user? there's already all user management code there to avoid duplication in different applications. Joakim, to the best of my knowledge used bits and pieces from Maven User but the implementation in plexus-security package is better in my opinion and has been worked on by more people (I've looked at it and agree though a critique of some things in p-sec in general is coming from me). Myself, Jesse, and Joakim were involved and the speed with which p-sec was integrated into Continuum is a testament to its ease of use. The user management is part of that system. On 9/28/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: +1 for the merge Emmanuel Jesse McConnell a écrit : > Over the course of the past 3 weeks I've worked with joakim on the > plexus-security effort to bring rbac based security to Archiva. > We succeeded. > > Last Friday (or so) I took the continuum/trunk and created the > rbac-integration branch. > I wanted from to test the integration of rbac based security, using > the plexus-security project, into continuum. > > It integrated beautifully, without a whole lot of work, in record > time, and is pretty functional now ... > > Some of the fun things that plexus-security brings with it are: > > * full separation between application webapp and security (lightweight > integration). > * proper modularization for security components (authentication, > authorization, policy, system, web, etc...) > * rbac (role based access control) authorization provider. > * full user management war overlay (using healthy chunk of maven- user > to make it happen) > * toggle-able guest user authorization. > * remember me and single sign on authentication. > * forced admin account creation (through use of interceptor) > * key based authentication (remember me, single sign on, new user > validation emails, and password resets). > * http auth filters (basic and digest). > * aggressive plexus utilization. > * aggressive xwork / webwork integration. > * xwork interceptors for force admin, auto login (remember me), > secured action, and environment checks. > * secured actions for all of the /security namespace and at least one > continuum secured action (these are enforced by the > pssSecureActionInterceptor) > * all the password validation, user management stuff (again maven-user > origins) > * continuum-security artifact containing the actual static and dynamic > roles, and a continuum role manager that merges permissions to the > core system, user, and guest users > * ifAuthorized, ifAnyAuthorized, elseAuthorized jsp tags. > * placeholders for ldap authentication, authorization and user details > retrieval using plexus ldap components > * ability to re-use Acegi for authentication > > I think it is very usable now, its a matter of some jsp and action > work to clean up some things and hide some other knobs and buttons. > > I'd like to get feedback and discussion from the others here about the > implementation, and consider a vote to merge it to trunk after that. I > believe it is stable enough to move forward with. > > jesse > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: distributed continuum
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. 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]
Re: Continuum 1.1 roadmap
On 3 Jul 06, at 9:30 AM 3 Jul 06, Brett Porter wrote: On 28/06/2006 8:40 PM, Jason van Zyl wrote: When we last discussed it on the development process, we talked about instead doing regular promotion of the automated builds (eg, roughly once a week we say "this is a stable build with something new/a good fix/etc, let's ask people to test it"). I'd really like to try that (and add anything to continuum to make it easier :) Yes, but we still have to make some official public releases. I don't think we can just release Continuum generated builds and then just release 1.1? Or do I misunderstand what you're talking about. I think we are talking about the same thing, but it's just mechanics. So a fundamental thing I think we need is regular builds that at least passed the basic integration tests (ie, they compiled and the server started). These are what we have now, though I'd rather they came from Continuum and were more easily accessible to joe schmo just coming to the web site. The next thing is regularly approved builds. Currently we schedule and do the alpha/beta thing, but what I'm thinking is not going through the whole release process that is time consuming and doing something more regular - ie every week or two we say "there's been a few new features, or a significant internal change, or some bad bugs fixed and we want people to test it", so we check a particular build is reasonably stable and then vote (or something) to promote it - and we put that up on the web site as the latest "test" build. It's somewhere between unstable nightlies and really stable releases. So you're suggesting we not doing any official alpha/beta releases? I guess what I'm thinking of is something like IDEA's EAP program. Then the final release would what we do now: produce an RC which we intend to be the actual binary, call for testers and vote. Release that, or produce another one, then push it out to the mirrors and announce. Cheers, Brett Jason van Zyl [EMAIL PROTECTED]
Re: Continuum 1.1 roadmap
On 28 Jun 06, at 10:52 AM 28 Jun 06, Emmanuel Venisse wrote: Jason van Zyl a écrit : On 27 Jun 06, at 10:04 PM 27 Jun 06, Emmanuel Venisse wrote: Hi, I started to define the roadmap of continuum 1.1. It will be done normally tomorrow. Are we deciding that these are the things are going to be in 1.1 and take as long as we need? I would prefer that myself. Looking below there I think that's a good list. I'd prefer too, but depends of the time we spend on each items. If we need lot of time on each items, perhaps we'll do an intermediate release. I assume for this we are going to release a series of alphas? How about for each major feature implemented we release an alpha? The major first things to do in this roadmap are: - Reimplementation of authentication/authorization management (CONTINUUM-542 and CONTINUUM-513): this will be done by carlos with acegi. Carlos will integrate acegi with plexus. This part must secure all requests in continuum and not only don't show some part of the interface. If a plexus component is made to integrate Acegi that's cool. As long as Continuum itself has an abstraction for security and Acegi is not coupled directly to Continuum that's fine. Normally, they won't be coupled. Carlos, can you add more informations? If the work is done in a branch we can just comment as the work commences. I'm sure I won't find the time but I would still like to try SASS which Patrick has been working on if I can. - Remove JDO (at least jpox) because it the source of lot of our issues +1 - implementation of continuum profiles and installation screens (CONTINUUM-44,CONTINUUM-59) +1 - integration of GBuild (CONTINUUM-563) +1 - implementation of project groups (CONTINUUM-30, CONTINUUM-289,CONTINUUM-290, CONTINUUM-291, CONTINUUM-292) +1 Other important things I'd want to see in it: - customization of the add project feature. In this part, I think to add a multi-project as a multiple projects or as a single project, scm connection string to use, add with a scm url, add all modules by a scm connection instead of an url contruction based on project url provided in the add screen +1 - build on dependencies changes +1 - add a tests result summary in build results +1 I'll add missing issues in jira tomorrow when I'll continue the roadmap. Cool, thanks Emmanuel. Emmanuel Jason van Zyl [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED]
Re: Continuum 1.1 roadmap
On 27 Jun 06, at 10:04 PM 27 Jun 06, Emmanuel Venisse wrote: Hi, I started to define the roadmap of continuum 1.1. It will be done normally tomorrow. Are we deciding that these are the things are going to be in 1.1 and take as long as we need? I would prefer that myself. Looking below there I think that's a good list. The major first things to do in this roadmap are: - Reimplementation of authentication/authorization management (CONTINUUM-542 and CONTINUUM-513): this will be done by carlos with acegi. Carlos will integrate acegi with plexus. This part must secure all requests in continuum and not only don't show some part of the interface. If a plexus component is made to integrate Acegi that's cool. As long as Continuum itself has an abstraction for security and Acegi is not coupled directly to Continuum that's fine. - Remove JDO (at least jpox) because it the source of lot of our issues +1 - implementation of continuum profiles and installation screens (CONTINUUM-44,CONTINUUM-59) +1 - integration of GBuild (CONTINUUM-563) +1 - implementation of project groups (CONTINUUM-30, CONTINUUM-289,CONTINUUM-290, CONTINUUM-291, CONTINUUM-292) +1 Other important things I'd want to see in it: - customization of the add project feature. In this part, I think to add a multi-project as a multiple projects or as a single project, scm connection string to use, add with a scm url, add all modules by a scm connection instead of an url contruction based on project url provided in the add screen +1 - build on dependencies changes +1 - add a tests result summary in build results +1 I'll add missing issues in jira tomorrow when I'll continue the roadmap. Cool, thanks Emmanuel. Emmanuel Jason van Zyl [EMAIL PROTECTED]
Re: Release Management for Maven/Continuum
Cool, thanks for posting that. Jason. On 13 Jun 06, at 10:51 PM 13 Jun 06, Jeremy Whitlock wrote: Hi all, This is an email that Jason sent me to give you a better understanding of the previous email I sent. Please feel free to comment, question or add suggestions to the effort. Take care, Jeremy -- Forwarded message -- From: Jason Van Zyl <[EMAIL PROTECTED]> Date: Jun 11, 2006 10:01 AM Subject: Releasing with Continuum To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Hey, I wrote a tiny diagram here: http://people.apache.org/~jvanzyl/ReleasingWithContinuum.pngpeople.apache.org/%7Ejvanzyl/ReleasingWithContinuum.png> I checked in some code into the release plugin for you. If you're watching the commit logs then you'll see notes I'm leaving for you and I've also marked todos for you with //TODO:JW so you can key off that if you're using eclipse or IDEA. In IDEA you can customize that sort of thing. What I've done so far is create the release descriptor model in the release plugin. When you update the release plugin you'll see it: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-release- plugin/src/main/mdo/ When you run the build, the java sources will be generated. You can see the configuration for modello in the POM for the release plugin. I added a note in the PrepareReleaseMojo with TODO:JW which you can take a peek at. Basically that's just the starting point as you'll have to add everything you need in order to make the release descriptor be populated, used and sent to Continuum. I will now create a little module in Continuum that will use the stuff I just created in the release plugin. Ultimately we will probably make a separate release management build and as you see Brett has already started the tool in the release plugin. So for now a module in Continuum that uses this will depend on a Maven plugin because it will need the release descriptor model but that's fine for now. Maybe you can think about separating out the release management tool in the release plugin as you go. Brett probably has some ideas on that. Ok, I will try to whip something off quick in Continuum for you. Jason van Zyl [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED]
Re: [vote] Release Continuum 1.0.3
+1 Emmanuel Venisse wrote: Hi, I've fixed some issues since latest RC (memory leak, performance...) Here is the latest RC. Please give it a try before voting. http://www.codehaus.org/~evenisse/continuum/ Let's do another 72h round of voting. +1/+0/-1 Here's my +1. Thanks, Emmanuel -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
Re: [vote] Release Continuum 1.0.3
+1 Emmanuel Venisse wrote: Hi, I've fixed some issues since latest RC (memory leak, performance...) Here is the latest RC. Please give it a try before voting. http://www.codehaus.org/~evenisse/continuum/ Let's do another 72h round of voting. +1/+0/-1 Here's my +1. Thanks, Emmanuel -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org We all have problems. How we deal with them is a measure of our worth. -- Unknown
Distributed Continuum (GBuild)
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
[jira] Created: (CONTINUUM-538) Create a tiny url mechansism so that a short url can be used for notifications
Create a tiny url mechansism so that a short url can be used for notifications -- Key: CONTINUUM-538 URL: http://jira.codehaus.org/browse/CONTINUUM-538 Project: Continuum Type: New Feature Components: Web interface Reporter: Jason van Zyl Assigned to: Jason van Zyl It would be nice to have simple short urls that point to build referenced in notifications. -- 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-254) Increase the length of the input fields in the web interface
Increase the length of the input fields in the web interface Key: CONTINUUM-254 URL: http://jira.codehaus.org/browse/CONTINUUM-254 Project: Continuum Type: Improvement Reporter: Jason van Zyl Fix For: 1.0-beta-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
[jira] Created: (CONTINUUM-253) Create a matrix of databases that Continuum can work with
Create a matrix of databases that Continuum can work with - Key: CONTINUUM-253 URL: http://jira.codehaus.org/browse/CONTINUUM-253 Project: Continuum Type: Task Reporter: Jason van Zyl Fix For: 1.0-beta-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
[jira] Updated: (CONTINUUM-245) Define what default information Continuum should populate on its first startup
[ http://jira.codehaus.org/browse/CONTINUUM-245?page=all ] Jason van Zyl updated CONTINUUM-245: Description: Continuum is becoming more configurable but it would still be nice if Continuum could run out of the box by picking up system information like the: o JDK (the one used to run Continuum) o Default schedule (hourly is probably fine using update mode) o Ant o Maven 1.x o Maven 2.x was: Continuum is becoming more configurable but it would still be nice if Continuum could run out of the box by picking up system information like the: o JDK (the one used to run Continuum) o Default schedule (hourly is probably fine using update mode) > Define what default information Continuum should populate on its first startup > -- > > Key: CONTINUUM-245 > URL: http://jira.codehaus.org/browse/CONTINUUM-245 > Project: Continuum > Type: Task > Reporter: Jason van Zyl > Fix For: 1.0-beta-1 > > > Continuum is becoming more configurable but it would still be nice if > Continuum could run out of the box by picking up system information like the: > o JDK (the one used to run Continuum) > o Default schedule (hourly is probably fine using update mode) > o Ant > o Maven 1.x > o Maven 2.x -- 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-245) Define what default information Continuum should populate on its first startup
Define what default information Continuum should populate on its first startup -- Key: CONTINUUM-245 URL: http://jira.codehaus.org/browse/CONTINUUM-245 Project: Continuum Type: Task Reporter: Jason van Zyl Fix For: 1.0-beta-1 Continuum is becoming more configurable but it would still be nice if Continuum could run out of the box by picking up system information like the: o JDK (the one used to run Continuum) o Default schedule (hourly is probably fine using update mode) -- 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-244) Create an m1 plugin that will add/update m1 projects in Continuum
Create an m1 plugin that will add/update m1 projects in Continuum - Key: CONTINUUM-244 URL: http://jira.codehaus.org/browse/CONTINUUM-244 Project: Continuum Type: New Feature Reporter: Jason van Zyl Fix For: 1.0-beta-1 Trygve and I chatted and figured that this approach might be easier then trying to pull in all the m1 code to read m1 POMs inside Continuum. The m1 Continuum plugin could read all the necessary project information (taking into account, property interpolation and entities) and submit it to a Continuum instance using the SOAP interface. -- 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] Closed: (CONTINUUM-66) m2 install should work for continuum-plexus-application
[ http://jira.codehaus.org/browse/CONTINUUM-66?page=all ] Jason van Zyl closed CONTINUUM-66: -- Resolution: Fixed Emmanuel has fixed this. > m2 install should work for continuum-plexus-application > --- > > Key: CONTINUUM-66 > URL: http://jira.codehaus.org/browse/CONTINUUM-66 > Project: Continuum > Type: Bug > Versions: 1.0-alpha-3 > Reporter: Brett Porter > Assignee: Trygve Laugstol > Priority: Minor > Fix For: 1.0-beta-1 > > > the plexus:* goals registered should bind to appropriate lifecycle phases > (package?) > We may need an assemble phase after package, before install as well. > This could possibly be done automatically by a type for the :app > goal (so its goal configuration would not be needed), but the runtime goals > must be listed. -- 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-230) Continuum should provide a useful URL when it notifies.
Continuum should provide a useful URL when it notifies. --- Key: CONTINUUM-230 URL: http://jira.codehaus.org/browse/CONTINUUM-230 Project: Continuum Type: Improvement Reporter: Jason van Zyl Assigned to: Emmanuel Venisse Fix For: 1.0-beta-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
[jira] Created: (CONTINUUM-228) Use profiles to control the generation of the runtime
Use profiles to control the generation of the runtime - Key: CONTINUUM-228 URL: http://jira.codehaus.org/browse/CONTINUUM-228 Project: Continuum Type: Improvement Reporter: Jason van Zyl We have development mode settings and production mode settings and a profile should be used to control this. -- 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] Closed: (CONTINUUM-224) Add artifactId to ContinuumProject for build order sorting
[ http://jira.codehaus.org/browse/CONTINUUM-224?page=all ] Jason van Zyl closed CONTINUUM-224: --- Resolution: Fixed Done. > Add artifactId to ContinuumProject for build order sorting > -- > > Key: CONTINUUM-224 > URL: http://jira.codehaus.org/browse/CONTINUUM-224 > Project: Continuum > Type: Improvement > Reporter: Jason van Zyl > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > We want to be able to create nodes using artifactId+groupId as is done in > maven itself. This way we can create a build order for Ant and Shell projects > too. -- 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] Closed: (CONTINUUM-227) Maven 2.x builder needs to populate the artifactId
[ http://jira.codehaus.org/browse/CONTINUUM-227?page=all ] Jason van Zyl closed CONTINUUM-227: --- Resolution: Fixed artifactId now populated. > Maven 2.x builder needs to populate the artifactId > -- > > Key: CONTINUUM-227 > URL: http://jira.codehaus.org/browse/CONTINUUM-227 > Project: Continuum > Type: Task > Reporter: Jason van Zyl > Fix For: 1.0-beta-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
[jira] Created: (CONTINUUM-227) Maven 2.x builder needs to populate the artifactId
Maven 2.x builder needs to populate the artifactId -- Key: CONTINUUM-227 URL: http://jira.codehaus.org/browse/CONTINUUM-227 Project: Continuum Type: Task Reporter: Jason van Zyl Fix For: 1.0-beta-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
[jira] Closed: (CONTINUUM-190) Improve validation of POM when importing either by URL/Upload
[ http://jira.codehaus.org/browse/CONTINUUM-190?page=all ] Jason van Zyl closed CONTINUUM-190: --- Resolution: Fixed These items are checked for now. > Improve validation of POM when importing either by URL/Upload > - > > Key: CONTINUUM-190 > URL: http://jira.codehaus.org/browse/CONTINUUM-190 > Project: Continuum > Type: Improvement > Reporter: Jason van Zyl > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > The things we need to check for: > o no scm (repository) element > o invalid scm (repository) element > -> the location must exist (can use the scm url validator) > o no ciManagement element > o invalid ciManagement element >-> make sure there is at least one notifier and the configuration is valid -- 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] Closed: (CONTINUUM-209) Update to the latest Maven SCM code
[ http://jira.codehaus.org/browse/CONTINUUM-209?page=all ] Jason van Zyl closed CONTINUUM-209: --- Resolution: Fixed Done. > Update to the latest Maven SCM code > --- > > Key: CONTINUUM-209 > URL: http://jira.codehaus.org/browse/CONTINUUM-209 > Project: Continuum > Type: Task > Reporter: Jason van Zyl > Assignee: Trygve Laugstol > > > The latest Maven SCM code is required for the blame mechanism. -- 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] Deleted: (CONTINUUM-209) Update to the latest Maven SCM code
[ http://jira.codehaus.org/browse/CONTINUUM-209?page=all ] Jason van Zyl deleted CONTINUUM-209: > Update to the latest Maven SCM code > --- > > Key: CONTINUUM-209 > URL: http://jira.codehaus.org/browse/CONTINUUM-209 > Project: Continuum > Type: Task > Reporter: Jason van Zyl > Assignee: Trygve Laugstol > > > The latest Maven SCM code is required for the blame mechanism. -- 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] Closed: (CONTINUUM-226) Maven 1.x builder needs to populate the artifactId
[ http://jira.codehaus.org/browse/CONTINUUM-226?page=all ] Jason van Zyl closed CONTINUUM-226: --- Resolution: Fixed > Maven 1.x builder needs to populate the artifactId > -- > > Key: CONTINUUM-226 > URL: http://jira.codehaus.org/browse/CONTINUUM-226 > Project: Continuum > Type: Task > Reporter: Jason van Zyl > Assignee: Jason van Zyl > Fix For: 1.0-beta-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
[jira] Created: (CONTINUUM-226) Maven 1.x builder needs to populate the artifactId
Maven 1.x builder needs to populate the artifactId -- Key: CONTINUUM-226 URL: http://jira.codehaus.org/browse/CONTINUUM-226 Project: Continuum Type: Task Reporter: Jason van Zyl Assigned to: Jason van Zyl Fix For: 1.0-beta-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
[jira] Created: (CONTINUUM-225) Collect all build/execution classes for a particular tool like Maven into a single package
Collect all build/execution classes for a particular tool like Maven into a single package -- Key: CONTINUUM-225 URL: http://jira.codehaus.org/browse/CONTINUUM-225 Project: Continuum Type: Improvement Reporter: Jason van Zyl Fix For: 1.0-beta-1 Right now there are build execution classes for Maven in one place and project builder classes for maven in another. We need to package them up into a single module for clarity. -- 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-224) Add artifactId to ContinuumProject for build order sorting
[ http://jira.codehaus.org/browse/CONTINUUM-224?page=all ] Jason van Zyl updated CONTINUUM-224: Assign To: Jason van Zyl > Add artifactId to ContinuumProject for build order sorting > -- > > Key: CONTINUUM-224 > URL: http://jira.codehaus.org/browse/CONTINUUM-224 > Project: Continuum > Type: Improvement > Reporter: Jason van Zyl > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > We want to be able to create nodes using artifactId+groupId as is done in > maven itself. This way we can create a build order for Ant and Shell projects > too. -- 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-224) Add artifactId to ContinuumProject for build order sorting
Add artifactId to ContinuumProject for build order sorting -- Key: CONTINUUM-224 URL: http://jira.codehaus.org/browse/CONTINUUM-224 Project: Continuum Type: Improvement Reporter: Jason van Zyl Fix For: 1.0-beta-1 We want to be able to create nodes using artifactId+groupId as is done in maven itself. This way we can create a build order for Ant and Shell projects too. -- 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
Re: svn commit: r216139 - /maven/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/core/DefaultContinuumCore.java
On Wed, 2005-07-13 at 11:17 +, [EMAIL PROTECTED] wrote: > Author: evenisse > Date: Wed Jul 13 04:17:03 2005 > New Revision: 216139 > > URL: http://svn.apache.org/viewcvs?rev=216139&view=rev > Log: > Find and use always the correct continuum version That's odd, this fix must have been backed out or overwritten: http://jira.codehaus.org/browse/CONTINUUM-112 Good catch. -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society
[jira] Commented: (CONTINUUM-223) URL validator doesn't accept url http://myserver/mypath
[ http://jira.codehaus.org/browse/CONTINUUM-223?page=comments#action_42740 ] Jason van Zyl commented on CONTINUUM-223: - It expects a document in there: http://foo.bar.com/foo.xml. Do you need it to be more lenient? > URL validator doesn't accept url http://myserver/mypath > --- > > Key: CONTINUUM-223 > URL: http://jira.codehaus.org/browse/CONTINUUM-223 > Project: Continuum > Type: Bug > Reporter: Emmanuel Venisse > Fix For: 1.0-beta-1 > > > http://localhost/pom.xml -- 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-54) Create a gump project builder
[ http://jira.codehaus.org/browse/CONTINUUM-54?page=all ] Jason van Zyl updated CONTINUUM-54: --- Assign To: (was: Emmanuel Venisse) > Create a gump project builder > - > > Key: CONTINUUM-54 > URL: http://jira.codehaus.org/browse/CONTINUUM-54 > Project: Continuum > Type: New Feature > Components: continuum-core > Reporter: Jason van Zyl > > -- 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-54) Create a gump project builder
[ http://jira.codehaus.org/browse/CONTINUUM-54?page=all ] Jason van Zyl updated CONTINUUM-54: --- Description: Version: (was: 1.0-beta-1) Fix Version: (was: 1.0-beta-1) Environment: > Create a gump project builder > - > > Key: CONTINUUM-54 > URL: http://jira.codehaus.org/browse/CONTINUUM-54 > Project: Continuum > Type: New Feature > Components: continuum-core > Reporter: Jason van Zyl > Assignee: Emmanuel Venisse > > -- 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-221) Document the outline of all features planned for 1.0
Document the outline of all features planned for 1.0 Key: CONTINUUM-221 URL: http://jira.codehaus.org/browse/CONTINUUM-221 Project: Continuum Type: Task Reporter: Jason van Zyl Assigned to: Jason van Zyl Fix For: 1.0-beta-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
[jira] Updated: (CONTINUUM-176) adding parent pom create duplicate continuum projects for all children
[ http://jira.codehaus.org/browse/CONTINUUM-176?page=all ] Jason van Zyl updated CONTINUUM-176: Assign To: Trygve Laugstol Description: adding my parent maven2 project to continuum creates a continuum project for each of my subprojects. the continuum project's start off with the label of my subprojects, but once the build run's they all revert to the label of the parent projects. the build process for each of the subproject's is the same as well. they don't actually just build the subproject. continuum builds the entire project. try using my project's pom at https://shard.dev.java.net/source/browse/*checkout*/shard/pom.xml for an example. was: adding my parent maven2 project to continuum creates a continuum project for each of my subprojects. the continuum project's start off with the label of my subprojects, but once the build run's they all revert to the label of the parent projects. the build process for each of the subproject's is the same as well. they don't actually just build the subproject. continuum builds the entire project. try using my project's pom at https://shard.dev.java.net/source/browse/*checkout*/shard/pom.xml for an example. Environment: Trygve, can you verify this is all good now. > adding parent pom create duplicate continuum projects for all children > -- > > Key: CONTINUUM-176 > URL: http://jira.codehaus.org/browse/CONTINUUM-176 > Project: Continuum > Type: Bug > Versions: 1.0-alpha-2 > Reporter: Ryan Sonnek > Assignee: Trygve Laugstol > Fix For: 1.0-beta-1 > > > adding my parent maven2 project to continuum creates a continuum project for > each of my subprojects. the continuum project's start off with the label of > my subprojects, but once the build run's they all revert to the label of the > parent projects. > the build process for each of the subproject's is the same as well. they > don't actually just build the subproject. continuum builds the entire > project. > try using my project's pom at > https://shard.dev.java.net/source/browse/*checkout*/shard/pom.xml for an > example. -- 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-45) ability to use snapshot versions instead
[ http://jira.codehaus.org/browse/CONTINUUM-45?page=all ] Jason van Zyl updated CONTINUUM-45: --- Fix Version: (was: 1.0-beta-1) Environment: > ability to use snapshot versions instead > > > Key: CONTINUUM-45 > URL: http://jira.codehaus.org/browse/CONTINUUM-45 > Project: Continuum > Type: New Feature > Reporter: Brett Porter > > > some profiles should build using all the latest artifacts regardless of what > the POM says (ala Gump). -- 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-169) relocate database and temp data
[ http://jira.codehaus.org/browse/CONTINUUM-169?page=comments#action_42626 ] Jason van Zyl commented on CONTINUUM-169: - This would be a tradeoff between making upgrading easier vs complete self containment. It's nice being able to unpack and go, but better web configuration would help with this. Anyone have any other thoughts on this? > relocate database and temp data > --- > > Key: CONTINUUM-169 > URL: http://jira.codehaus.org/browse/CONTINUUM-169 > Project: Continuum > Type: Bug > Reporter: Brett Porter > Fix For: 1.0-beta-1 > > > the temp checkouts should be named something sensible and configurable - > defaulted to something outside of the continuum install if possible > the database should likewise be stored outside of the continuum install -- 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] Assigned: (CONTINUUM-140) Allow the use of the CC in the web UI
[ http://jira.codehaus.org/browse/CONTINUUM-140?page=all ] Jason van Zyl reassigned CONTINUUM-140: --- Assign To: Jason van Zyl > Allow the use of the CC in the web UI > - > > Key: CONTINUUM-140 > URL: http://jira.codehaus.org/browse/CONTINUUM-140 > Project: Continuum > Type: New Feature > Versions: 1.0-beta-1 > Reporter: Jason van Zyl > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > This will require some changes in the UI to make this work but we can assess > in alpha-3 -- 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-54) Create a gump project builder
[ http://jira.codehaus.org/browse/CONTINUUM-54?page=all ] Jason van Zyl updated CONTINUUM-54: --- Assign To: Emmanuel Venisse Summary: Create a gump project builder (was: Allow the addition of a project using a gump descriptor) > Create a gump project builder > - > > Key: CONTINUUM-54 > URL: http://jira.codehaus.org/browse/CONTINUUM-54 > Project: Continuum > Type: New Feature > Components: continuum-core > Versions: 1.0-beta-1 > Reporter: Jason van Zyl > Assignee: Emmanuel Venisse > Fix For: 1.0-beta-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
[jira] Updated: (CONTINUUM-209) Update to the latest Maven SCM code
[ http://jira.codehaus.org/browse/CONTINUUM-209?page=all ] Jason van Zyl updated CONTINUUM-209: Fix Version: 1.0-beta-1 > Update to the latest Maven SCM code > --- > > Key: CONTINUUM-209 > URL: http://jira.codehaus.org/browse/CONTINUUM-209 > Project: Continuum > Type: Task > Reporter: Jason van Zyl > Assignee: Trygve Laugstol > Fix For: 1.0-beta-1 > > > The latest Maven SCM code is required for the blame mechanism. -- 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] Assigned: (CONTINUUM-193) Collapse the CheckoutScmResult and UpdateScmResult
[ http://jira.codehaus.org/browse/CONTINUUM-193?page=all ] Jason van Zyl reassigned CONTINUUM-193: --- Assign To: Trygve Laugstol > Collapse the CheckoutScmResult and UpdateScmResult > -- > > Key: CONTINUUM-193 > URL: http://jira.codehaus.org/browse/CONTINUUM-193 > Project: Continuum > Type: Task > Components: continuum-web, continuum-core > Reporter: Trygve Laugstol > Assignee: Trygve Laugstol > Fix For: 1.0-beta-1 > > > Having two separate objects for this is just overkill and makes life more > complicated than it has to be. Right not the DefaultBuildController has to > transform the CheckOutScmResult to a UpdateScmResult and that should be > removed. -- 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] Assigned: (CONTINUUM-41) sort by different columns
[ http://jira.codehaus.org/browse/CONTINUUM-41?page=all ] Jason van Zyl reassigned CONTINUUM-41: -- Assign To: Jason van Zyl > sort by different columns > - > > Key: CONTINUUM-41 > URL: http://jira.codehaus.org/browse/CONTINUUM-41 > Project: Continuum > Type: New Feature > Reporter: Brett Porter > Assignee: Jason van Zyl > Priority: Trivial > Fix For: 1.0-beta-1 > > > it would be nice to be able to sort by the various columns in the summary > page, in particular so you can elevate failed projects to the top. -- 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] Assigned: (CONTINUUM-41) sort by different columns
[ http://jira.codehaus.org/browse/CONTINUUM-41?page=all ] Jason van Zyl reassigned CONTINUUM-41: -- Assign To: Jason van Zyl > sort by different columns > - > > Key: CONTINUUM-41 > URL: http://jira.codehaus.org/browse/CONTINUUM-41 > Project: Continuum > Type: New Feature > Reporter: Brett Porter > Assignee: Jason van Zyl > Priority: Trivial > Fix For: 1.0-beta-1 > > > it would be nice to be able to sort by the various columns in the summary > page, in particular so you can elevate failed projects to the top. -- 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] Assigned: (CONTINUUM-46) view the build schedule
[ http://jira.codehaus.org/browse/CONTINUUM-46?page=all ] Jason van Zyl reassigned CONTINUUM-46: -- Assign To: Jason van Zyl > view the build schedule > --- > > Key: CONTINUUM-46 > URL: http://jira.codehaus.org/browse/CONTINUUM-46 > Project: Continuum > Type: New Feature > Reporter: Brett Porter > Assignee: Jason van Zyl > Priority: Minor > Fix For: 1.0-beta-1 > > > it would be good to be able to display an overall view of the build schedule > so you can see what builds are coming up, or just done. -- 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] Assigned: (CONTINUUM-44) multiple profiles
[ http://jira.codehaus.org/browse/CONTINUUM-44?page=all ] Jason van Zyl reassigned CONTINUUM-44: -- Assign To: Jason van Zyl > multiple profiles > - > > Key: CONTINUUM-44 > URL: http://jira.codehaus.org/browse/CONTINUUM-44 > Project: Continuum > Type: New Feature > Reporter: Brett Porter > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > would like to be able to define a profile (which can include certain > environmental things such as the version of m2 to use, the JDK version, etc). > Profiles should be able to be used globally, per group or per project. In > this way, you could build certain projects under a variety of different JDKs > for example. -- 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] Assigned: (CONTINUUM-68) Make Continuum control database initialization and destruction.
[ http://jira.codehaus.org/browse/CONTINUUM-68?page=all ] Jason van Zyl reassigned CONTINUUM-68: -- Assign To: Trygve Laugstol > Make Continuum control database initialization and destruction. > --- > > Key: CONTINUUM-68 > URL: http://jira.codehaus.org/browse/CONTINUUM-68 > Project: Continuum > Type: Improvement > Components: continuum-core > Versions: 1.0-alpha-1 > Reporter: Trygve Laugstol > Assignee: Trygve Laugstol > Fix For: 1.0-beta-1 > > > Continuum should be able to autodetect if the application has been properly > configured and if not autmatically set up a database given a configuration > either from the user or from a configuration file. This should possibly be > integrated into the web view so the application won't start up all the way > without a proper storage. -- 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] Assigned: (CONTINUUM-43) multiple schedules and schedule selection
[ http://jira.codehaus.org/browse/CONTINUUM-43?page=all ] Jason van Zyl reassigned CONTINUUM-43: -- Assign To: Jason van Zyl > multiple schedules and schedule selection > - > > Key: CONTINUUM-43 > URL: http://jira.codehaus.org/browse/CONTINUUM-43 > Project: Continuum > Type: New Feature > Reporter: Brett Porter > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > it would be good to be able to add new schedules and be able to select them > on a per project or per group basis. > Some projects would like to be able to build much more frequently as they > have frequent changes. -- 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] Assigned: (CONTINUUM-58) Build all dependent projects.
[ http://jira.codehaus.org/browse/CONTINUUM-58?page=all ] Jason van Zyl reassigned CONTINUUM-58: -- Assign To: Jason van Zyl > Build all dependent projects. > - > > Key: CONTINUUM-58 > URL: http://jira.codehaus.org/browse/CONTINUUM-58 > Project: Continuum > Type: New Feature > Reporter: Trygve Laugstol > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > When building foo-core, foo-web and foo-xml-rpc should be built aswell to > make sure that any changes to the core didn't break anything downstream. -- 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] Assigned: (CONTINUUM-125) Export/Import projects, configuration and history
[ http://jira.codehaus.org/browse/CONTINUUM-125?page=all ] Jason van Zyl reassigned CONTINUUM-125: --- Assign To: Emmanuel Venisse This should allow for complete backup and restoration of continuum while accounting for changes in the data structure. > Export/Import projects, configuration and history > - > > Key: CONTINUUM-125 > URL: http://jira.codehaus.org/browse/CONTINUUM-125 > Project: Continuum > Type: Task > Components: continuum-core, continuum-xmlrpc > Reporter: Trygve Laugstol > Assignee: Emmanuel Venisse > Fix For: 1.0-beta-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
[jira] Assigned: (CONTINUUM-139) Design per project configuration
[ http://jira.codehaus.org/browse/CONTINUUM-139?page=all ] Jason van Zyl reassigned CONTINUUM-139: --- Assign To: Jason van Zyl > Design per project configuration > > > Key: CONTINUUM-139 > URL: http://jira.codehaus.org/browse/CONTINUUM-139 > Project: Continuum > Type: Task > Versions: 1.0-alpha-3 > Reporter: Jason van Zyl > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > We need to design the per project configuration and figure out how to display > this in the web UI. -- 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] Assigned: (CONTINUUM-30) Project grouping features
[ http://jira.codehaus.org/browse/CONTINUUM-30?page=all ] Jason van Zyl reassigned CONTINUUM-30: -- Assign To: Jason van Zyl > Project grouping features > - > > Key: CONTINUUM-30 > URL: http://jira.codehaus.org/browse/CONTINUUM-30 > Project: Continuum > Type: New Feature > Versions: 1.0-alpha-3 > Reporter: Jason van Zyl > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > It would be nice to start incorporating some functionality based on groupIds. > Sorting by groupId, or a separate page for projects with the same groupId, or > reports for a whole groupId. Say a summary failure report with links to > details instead of 10 different emails. -- 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] Assigned: (CONTINUUM-145) Allow the creation of template project configurations
[ http://jira.codehaus.org/browse/CONTINUUM-145?page=all ] Jason van Zyl reassigned CONTINUUM-145: --- Assign To: Jason van Zyl > Allow the creation of template project configurations > - > > Key: CONTINUUM-145 > URL: http://jira.codehaus.org/browse/CONTINUUM-145 > Project: Continuum > Type: New Feature > Reporter: Jason van Zyl > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > For a given project type, say m2, allow the user the define template values > that will be used when new projects of that type are created. -- 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] Assigned: (CONTINUUM-156) should validate that an updated pom doesn't change too drastically
[ http://jira.codehaus.org/browse/CONTINUUM-156?page=all ] Jason van Zyl reassigned CONTINUUM-156: --- Assign To: Jason van Zyl > should validate that an updated pom doesn't change too drastically > -- > > Key: CONTINUUM-156 > URL: http://jira.codehaus.org/browse/CONTINUUM-156 > Project: Continuum > Type: Improvement > Reporter: Brett Porter > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > I added maven-core's POM, which is using a post -alpha-2 technique of > inheriting the SCM connection URL and appending the artifact ID. > This resulted in the new SCM URL being different and so it checked out the > root POM and proceeded to checkout all of maven/components/trunk. > IF the group ID/artifact ID of the POM changes on update, I think this needs > to go into an error state that requires user intervention to either accept it > has changed, or find out what is wrong. -- 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] Assigned: (CONTINUUM-117) Blame mechanism
[ http://jira.codehaus.org/browse/CONTINUUM-117?page=all ] Jason van Zyl reassigned CONTINUUM-117: --- Assign To: Jason van Zyl > Blame mechanism > --- > > Key: CONTINUUM-117 > URL: http://jira.codehaus.org/browse/CONTINUUM-117 > Project: Continuum > Type: New Feature > Versions: 1.0-alpha-3 > Reporter: Jason van Zyl > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > When a build breaks we need to be able to look at the ID(s) in the last set > of changes that broke a build so that we can track and notify. -- 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] Assigned: (CONTINUUM-143) We need to categorize error states and display them useful messages to the user
[ http://jira.codehaus.org/browse/CONTINUUM-143?page=all ] Jason van Zyl reassigned CONTINUUM-143: --- Assign To: Jason van Zyl > We need to categorize error states and display them useful messages to the > user > --- > > Key: CONTINUUM-143 > URL: http://jira.codehaus.org/browse/CONTINUUM-143 > Project: Continuum > Type: Improvement > Versions: 1.0-alpha-3 > Reporter: Jason van Zyl > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > Right now we're only tracking checkout errors but we need to categorize all > error so that we can easily extract them and display useful messages to the > user. -- 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] Closed: (CONTINUUM-27) Display the type of the component that was built
[ http://jira.codehaus.org/browse/CONTINUUM-27?page=all ] Jason van Zyl closed CONTINUUM-27: -- Resolution: Won't Fix Now handled transparently by the install phase. > Display the type of the component that was built > > > Key: CONTINUUM-27 > URL: http://jira.codehaus.org/browse/CONTINUUM-27 > Project: Continuum > Type: Improvement > Reporter: Emmanuel Venisse > Fix For: 1.0-beta-1 > > > And the type of the component can be help to find wich default goal we can > run. > pom => pom:install > jar(or empty) => jar:install > war => war:install > plugin => plugin:install > ... -- 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] Assigned: (CONTINUUM-197) Improve the start page of the web application
[ http://jira.codehaus.org/browse/CONTINUUM-197?page=all ] Jason van Zyl reassigned CONTINUUM-197: --- Assign To: Jason van Zyl > Improve the start page of the web application > - > > Key: CONTINUUM-197 > URL: http://jira.codehaus.org/browse/CONTINUUM-197 > Project: Continuum > Type: Improvement > Versions: 1.0-alpha-2 > Reporter: Trygve Laugstol > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > Currently the web application only has a link saying "GO HERE" which isn't > exactly elegant. -- 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] Assigned: (CONTINUUM-203) Plexus runtime should have solaris capability
[ http://jira.codehaus.org/browse/CONTINUUM-203?page=all ] Jason van Zyl reassigned CONTINUUM-203: --- Assign To: Trygve Laugstol > Plexus runtime should have solaris capability > - > > Key: CONTINUUM-203 > URL: http://jira.codehaus.org/browse/CONTINUUM-203 > Project: Continuum > Type: Improvement > Reporter: Jason van Zyl > Assignee: Trygve Laugstol > Fix For: 1.0-beta-1 > > > The plexus runtime generator needs to be improved to have this. -- 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] Assigned: (CONTINUUM-152) bad ID leads to confusing page
[ http://jira.codehaus.org/browse/CONTINUUM-152?page=all ] Jason van Zyl reassigned CONTINUUM-152: --- Assign To: Jason van Zyl > bad ID leads to confusing page > -- > > Key: CONTINUUM-152 > URL: http://jira.codehaus.org/browse/CONTINUUM-152 > Project: Continuum > Type: Bug > Components: continuum-web > Reporter: Brett Porter > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > when hitting back, the project I had earlier deleted was there (I'll be > filing a separate bug for setting an expiry). > Hitting "info" on the now non-existant project brought the project info page > with unpopulated vars $project.name instead of an error page. I presume > others are similar. -- 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] Assigned: (CONTINUUM-190) Improve validation of POM when importing either by URL/Upload
[ http://jira.codehaus.org/browse/CONTINUUM-190?page=all ] Jason van Zyl reassigned CONTINUUM-190: --- Assign To: Jason van Zyl > Improve validation of POM when importing either by URL/Upload > - > > Key: CONTINUUM-190 > URL: http://jira.codehaus.org/browse/CONTINUUM-190 > Project: Continuum > Type: Improvement > Reporter: Jason van Zyl > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > The things we need to check for: > o no scm (repository) element > o invalid scm (repository) element > -> the location must exist (can use the scm url validator) > o no ciManagement element > o invalid ciManagement element >-> make sure there is at least one notifier and the configuration is valid -- 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-199) If you enter an m1 POM in the m2 entry screen it just silenty fails and returns to the summary screen.
[ http://jira.codehaus.org/browse/CONTINUUM-199?page=all ] Jason van Zyl updated CONTINUUM-199: Version: (was: 1.0-beta-1) 1.0-alpha-3 Fix Version: (was: 1.0-beta-1) 1.0-alpha-3 I believe this is related to the change the in the way the results are created when projects are built from metadata. > If you enter an m1 POM in the m2 entry screen it just silenty fails and > returns to the summary screen. > -- > > Key: CONTINUUM-199 > URL: http://jira.codehaus.org/browse/CONTINUUM-199 > Project: Continuum > Type: Bug > Versions: 1.0-alpha-3 > Reporter: Jason van Zyl > Fix For: 1.0-alpha-3 > > > Need to look and see what's happening in the internals. Not a likely course > of action but will definitely happen. -- 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-217) The m1 builder cannot deal with POMs with elements so don't allow them.
[ http://jira.codehaus.org/browse/CONTINUUM-217?page=all ] Jason van Zyl updated CONTINUUM-217: Fix Version: 1.0-alpha-3 > The m1 builder cannot deal with POMs with elements so don't allow > them. > - > > Key: CONTINUUM-217 > URL: http://jira.codehaus.org/browse/CONTINUUM-217 > Project: Continuum > Type: Improvement > Versions: 1.0-alpha-3 > Reporter: Jason van Zyl > Assignee: Jason van Zyl > Fix For: 1.0-alpha-3 > > > We can only deal with the parent POM or encapsulated m1 POMs. -- 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-218) Problems while creating projects from metadata are stored in results and not processed
Problems while creating projects from metadata are stored in results and not processed -- Key: CONTINUUM-218 URL: http://jira.codehaus.org/browse/CONTINUUM-218 Project: Continuum Type: Bug Reporter: Jason van Zyl Assigned to: Jason van Zyl Fix For: 1.0-alpha-3 An exception used to be thrown which was shown in a templates. Now it just silently passes through and garbage shows up in summary. -- 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-217) The m1 builder cannot deal with POMs with elements so don't allow them.
The m1 builder cannot deal with POMs with elements so don't allow them. - Key: CONTINUUM-217 URL: http://jira.codehaus.org/browse/CONTINUUM-217 Project: Continuum Type: Improvement Versions: 1.0-alpha-3 Reporter: Jason van Zyl Assigned to: Jason van Zyl We can only deal with the parent POM or encapsulated m1 POMs. -- 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] Closed: (CONTINUUM-216) Move org.apache.maven.continuum.network code out of Continuum
[ http://jira.codehaus.org/browse/CONTINUUM-216?page=all ] Jason van Zyl closed CONTINUUM-216: --- Resolution: Fixed Code has been (re)moved. > Move org.apache.maven.continuum.network code out of Continuum > - > > Key: CONTINUUM-216 > URL: http://jira.codehaus.org/browse/CONTINUUM-216 > Project: Continuum > Type: Task > Versions: 1.0-beta-1 > Reporter: Jason van Zyl > Assignee: Trygve Laugstol > > > We don't use this code, for remoting we'll use xmlrpc or SOAP. -- 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-216) Move org.apache.maven.continuum.network code out of Continuum
Move org.apache.maven.continuum.network code out of Continuum - Key: CONTINUUM-216 URL: http://jira.codehaus.org/browse/CONTINUUM-216 Project: Continuum Type: Task Versions: 1.0-beta-1 Reporter: Jason van Zyl Assigned to: Trygve Laugstol We don't use this code, for remoting we'll use xmlrpc or SOAP. -- 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-214) Integrate and test the Jabber notifier
Integrate and test the Jabber notifier -- Key: CONTINUUM-214 URL: http://jira.codehaus.org/browse/CONTINUUM-214 Project: Continuum Type: Task Versions: 1.0-beta-1 Reporter: Jason van Zyl Assigned to: Emmanuel Venisse Fix For: 1.0-beta-1 The m2 test projects we have can be augmented to specify a jabber notifier so testing wouldn't require any additions to the web interface. -- 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] Assigned: (CONTINUUM-187) Add yahoo messenger notifier
[ http://jira.codehaus.org/browse/CONTINUUM-187?page=all ] Jason van Zyl reassigned CONTINUUM-187: --- Assign To: Emmanuel Venisse If we can't find a license that is suitable we might be able to put the component somewhere else. That's not ideal but so many people use yahoo messenging. > Add yahoo messenger notifier > > > Key: CONTINUUM-187 > URL: http://jira.codehaus.org/browse/CONTINUUM-187 > Project: Continuum > Type: Improvement > Components: continuum-core > Reporter: Emmanuel Venisse > Assignee: Emmanuel Venisse > Fix For: 1.0-beta-1 > > > Use jymsg (http://jymsg9.sourceforge.net/) > http://www.devx.com/Java/Article/22546/0/page/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
[jira] Created: (CONTINUUM-213) Mail sender needs to be able to deal with authorization on the server
Mail sender needs to be able to deal with authorization on the server - Key: CONTINUUM-213 URL: http://jira.codehaus.org/browse/CONTINUUM-213 Project: Continuum Type: New Feature Reporter: Jason van Zyl Assigned to: Emmanuel Venisse Fix For: 1.0-beta-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
[jira] Assigned: (CONTINUUM-137) Store dependency information at the ContinuumProject level
[ http://jira.codehaus.org/browse/CONTINUUM-137?page=all ] Jason van Zyl reassigned CONTINUUM-137: --- Assign To: Jason van Zyl > Store dependency information at the ContinuumProject level > -- > > Key: CONTINUUM-137 > URL: http://jira.codehaus.org/browse/CONTINUUM-137 > Project: Continuum > Type: New Feature > Versions: 1.0-alpha-3 > Reporter: Jason van Zyl > Assignee: Jason van Zyl > Fix For: 1.0-beta-1 > > > In order to be able to build in any deterministic order we need dependency > information on all the projects entered into the system. -- 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] Assigned: (CONTINUUM-208) If an SCM command fails it would be useful to see the command that caused the failure
[ http://jira.codehaus.org/browse/CONTINUUM-208?page=all ] Jason van Zyl reassigned CONTINUUM-208: --- Assign To: Trygve Laugstol > If an SCM command fails it would be useful to see the command that caused the > failure > - > > Key: CONTINUUM-208 > URL: http://jira.codehaus.org/browse/CONTINUUM-208 > Project: Continuum > Type: Improvement > Reporter: Jason van Zyl > Assignee: Trygve Laugstol > Fix For: 1.0-beta-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
[jira] Assigned: (CONTINUUM-39) build in the correct order
[ http://jira.codehaus.org/browse/CONTINUUM-39?page=all ] Jason van Zyl reassigned CONTINUUM-39: -- Assign To: Jason van Zyl (was: Trygve Laugstol) > build in the correct order > -- > > Key: CONTINUUM-39 > URL: http://jira.codehaus.org/browse/CONTINUUM-39 > Project: Continuum > Type: Improvement > Versions: 1.0-alpha-3 > Reporter: Brett Porter > Assignee: Jason van Zyl > Priority: Critical > Fix For: 1.0-beta-1 > > > I'm unsure if this is already the case - it didn't appear to be. > If a project is going to depend on the output of another scheduled continuum > build (ie dependency id including version matches that of the other project's > id), then they should be built in the correct order, as in the reactor. -- 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-212) Add StarTeam provider to Continuum
Add StarTeam provider to Continuum -- Key: CONTINUUM-212 URL: http://jira.codehaus.org/browse/CONTINUUM-212 Project: Continuum Type: New Feature Reporter: Jason van Zyl Assigned to: Emmanuel Venisse Fix For: 1.0-beta-1 Emmanuel, could work with Dan Tran to try and integrate StarTeam into Continuum? -- 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] Assigned: (CONTINUUM-186) Can't set password in SCM url and neither a field is available for it
[ http://jira.codehaus.org/browse/CONTINUUM-186?page=all ] Jason van Zyl reassigned CONTINUUM-186: --- Assign To: Emmanuel Venisse > Can't set password in SCM url and neither a field is available for it > - > > Key: CONTINUUM-186 > URL: http://jira.codehaus.org/browse/CONTINUUM-186 > Project: Continuum > Type: Improvement > Versions: 1.0-alpha-2 > Environment: Windows - CVS - Ant > Reporter: Erik Bengtson > Assignee: Emmanuel Venisse > Priority: Blocker > Fix For: 1.0-beta-1 > > > I have the following url > scm:cvs:pserver:user:[EMAIL PROTECTED]:/cvsroot:module > With the above url it says, invalid url. We need a place to set the password > for cvs login -- 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] Assigned: (CONTINUUM-183) Should be able to build without using SCM.
[ http://jira.codehaus.org/browse/CONTINUUM-183?page=all ] Jason van Zyl reassigned CONTINUUM-183: --- Assign To: Trygve Laugstol Trygve, you seem to have a plan for this, maybe you can work with Simon to get this going. > Should be able to build without using SCM. > -- > > Key: CONTINUUM-183 > URL: http://jira.codehaus.org/browse/CONTINUUM-183 > Project: Continuum > Type: Wish > Components: continuum-core > Versions: 1.0-alpha-2 > Environment: x86 > Windows NT 4.0 > j2sdk1.4.2_05 > maven 1.0.2 > Reporter: Simon Richardson > Assignee: Trygve Laugstol > Priority: Blocker > Fix For: 1.0-beta-1 > > > The scm module does not support our version control system and I wondered if > there was a way to circumvent the scm aspect of continuum so that it only > builds what is on the file system? -- 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] Assigned: (CONTINUUM-204) Add SOAP interface using xfire
[ http://jira.codehaus.org/browse/CONTINUUM-204?page=all ] Jason van Zyl reassigned CONTINUUM-204: --- Assign To: Dan Diephouse Dan, what's the full status on this? > Add SOAP interface using xfire > -- > > Key: CONTINUUM-204 > URL: http://jira.codehaus.org/browse/CONTINUUM-204 > Project: Continuum > Type: New Feature > Reporter: Jason van Zyl > Assignee: Dan Diephouse > Fix For: 1.0-beta-1 > > > Dan will be taking care of this. -- 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] Closed: (CONTINUUM-200) Employ cascading delete for project builds
[ http://jira.codehaus.org/browse/CONTINUUM-200?page=all ] Jason van Zyl closed CONTINUUM-200: --- Resolution: Fixed This is now working. > Employ cascading delete for project builds > -- > > Key: CONTINUUM-200 > URL: http://jira.codehaus.org/browse/CONTINUUM-200 > Project: Continuum > Type: Improvement > Reporter: Jason van Zyl > Fix For: 1.0-beta-1 > > > The method of deleting builds from a project is cumbersome. Any reason we're > not using the cascading delete features in JPOX? -- 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] Assigned: (CONTINUUM-171) exception in failed checkout is not helpful
[ http://jira.codehaus.org/browse/CONTINUUM-171?page=all ] Jason van Zyl reassigned CONTINUUM-171: --- Assign To: Trygve Laugstol > exception in failed checkout is not helpful > --- > > Key: CONTINUUM-171 > URL: http://jira.codehaus.org/browse/CONTINUUM-171 > Project: Continuum > Type: Bug > Reporter: Brett Porter > Assignee: Trygve Laugstol > Fix For: 1.0-beta-1 > > > the exception propogated for a failed checkout doesn't report what actually > went wrong (in my case, it attempted to use a directory 1 which was left over > from before I had blown away the db, but already existed). -- 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] Assigned: (CONTINUUM-201) Convert IT tests to Java
[ http://jira.codehaus.org/browse/CONTINUUM-201?page=all ] Jason van Zyl reassigned CONTINUUM-201: --- Assign To: Trygve Laugstol > Convert IT tests to Java > > > Key: CONTINUUM-201 > URL: http://jira.codehaus.org/browse/CONTINUUM-201 > Project: Continuum > Type: Task > Reporter: Jason van Zyl > Assignee: Trygve Laugstol > Fix For: 1.0-beta-1 > > > They python scripts are proving cumbersome and will probably make it hard for > most java developers to dig in. -- 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] Closed: (CONTINUUM-207) Continuum should be in sync with the version of m2 used by the CI machine
[ http://jira.codehaus.org/browse/CONTINUUM-207?page=all ] Jason van Zyl closed CONTINUUM-207: --- Resolution: Fixed This is resolved now by letting MavenSettingsBuilder use its default values. > Continuum should be in sync with the version of m2 used by the CI machine > - > > Key: CONTINUUM-207 > URL: http://jira.codehaus.org/browse/CONTINUUM-207 > Project: Continuum > Type: Task > Reporter: Jason van Zyl > Fix For: 1.0-alpha-3 > > > Continuum should use the same repository and settings that m2 does on the CI > machine. -- 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-211) Improve error message when ScmUpdate fails
Improve error message when ScmUpdate fails -- Key: CONTINUUM-211 URL: http://jira.codehaus.org/browse/CONTINUUM-211 Project: Continuum Type: Improvement Reporter: Jason van Zyl Assigned to: Trygve Laugstol Fix For: 1.0-beta-1 Add the maven-plexus-plugin POM to see an example currently of what the error message looks like. You can look in the logs but it would be nice to see on the console what the problem is. -- 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-210) Use the new slimdog mojo for web testing
Use the new slimdog mojo for web testing Key: CONTINUUM-210 URL: http://jira.codehaus.org/browse/CONTINUUM-210 Project: Continuum Type: Task Reporter: Jason van Zyl Fix For: 1.0-beta-1 Thanks to John we can use a mojo. -- 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-210) Use the new slimdog mojo for web testing
[ http://jira.codehaus.org/browse/CONTINUUM-210?page=all ] Jason van Zyl updated CONTINUUM-210: Assign To: Emmanuel Venisse Fix Version: 1.0-beta-1 > Use the new slimdog mojo for web testing > > > Key: CONTINUUM-210 > URL: http://jira.codehaus.org/browse/CONTINUUM-210 > Project: Continuum > Type: Task > Reporter: Jason van Zyl > Assignee: Emmanuel Venisse > Fix For: 1.0-beta-1 > > > Thanks to John we can use a mojo. -- 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-209) Update to the latest Maven SCM code
Update to the latest Maven SCM code --- Key: CONTINUUM-209 URL: http://jira.codehaus.org/browse/CONTINUUM-209 Project: Continuum Type: Task Reporter: Jason van Zyl Assigned to: Trygve Laugstol The latest Maven SCM code is required for the blame mechanism. -- 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
