You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by James House <ja...@medibuy.com> on 2001/03/22 23:15:31 UTC
New Subprojects
Hi,
I'm interested in starting an open source project or two, and would like
them to fall under an Apache style license.
I'd also be happy for them to fall under the Jakarta umbrella, and am
curious what I'd need to do to have them do so
(otherwise I'll slap them up on sourceforge or somewhere).
Here's a description of the two related projects
(PLEASE let me know if you know of any existing open source projects that
are similar):
Project 1: an Enterprise Job Scheduler
=====================================
Description:
A job scheduling system that can handle the scheduling of thousands
(hopefully millions) of jobs, and cause them to be processed via a variety
of J2SE and J2EE mechanisms.
Basic Desired Features:
* Scalable & Robust (duh :)
* Able to handle hundreds of thousands or even millions of jobs
* Job persistence (survives crashes, reboots, etc.)
* Light-weight enough to be impeded within a simple stand-alone java app
* Able to be contained within a J2EE app-server environment
* Able to be used remotely from any Java environment (scheduler runs
stand-alone)
* Jobs are scheduled to run once at a given time, or recurring with
Cron-like expressions
* Able to cancel/skip/alter/etc. existing jobs
* When the time arrives for a job to fire, the scheduler should be able to:
- call any Java object implementing a specific 'listener' interface
- call any Session EJB implementing a specific interface
- pass a JMS message to a specified topic or queue
- other java/J2EE mechanisms?
* When a job is created, an arbitrary serializable object can be associated
with it, and at the time of job firing, that object is passed to the
listener(s) and/or sent to the JMS destination
* You name it
Background:
I created a rudimentary job scheduler (with some of the above features) a
couple years back, and made it open source, though nothing much was ever
done with it because it wasn't publicized at all. It was called JaCron (for
"java cron") -- this could be used as the starting point for the project...
if it is made part of Jakarta, perhaps we could rename it to "Jakron" or
some other more spiffy sounding name.
I have not been able to locate any similar open source project with quick
browsing of sourceforge and a few other places, so I feel this is a real
need. Many products require a scheduler such as this.
I found a similar product this morning called "Flux" - it has most of the
features I'm looking for, but it is commercial. They do however publish a
public interface for job scheduling that they suggest other projects should
implement (they're proposing a standard API).
Does anyone else know of a standard / api for doing job scheduling in Java?
Project 2: a Workflow Engine / Process Automator
=====================================
Description:
An engine for doing Workflow and Process Automation within or without a J2EE
application server.
Desired Features:
* I haven't put much thought into this yet, but I feel this is a real need
in the open source world unless someone can tell me of an existing one?
In case you're not sure what I'm referring to, here's a product of BEA's
that is similar to what I'm envisioning:
http://www.bea.com/products/weblogic/integrator/datasheet.shtml
Anyone interested in participating in either of these please contact me:
james@interobjective.com
I'd especially like to hear from someone directly involved with the Jakarta
project about if/how these could become sub-projects.
Thanks,
James
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Jon Stevens <jo...@latchkey.com>.
on 3/22/01 8:23 PM, "Peter Donald" <do...@apache.org> wrote:
>> Ok. Remember the motivation is to provide software components that can
>> be shared across projects. If they are tailored to one specific
>> framework, they won't easily be able to work in another.
>>
>> If you make it more general, then I assume more people can share the
>> software.
>
> It is better to get a little reuse than none at all.
No shit. I hate this mentality of "if it doesn't do everything that i need,
i need to start over and re-implement everything from scratch"...
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Peter Donald <do...@apache.org>.
At 11:51 22/3/01 -0500, Geir Magnusson Jr. wrote:
>Peter Donald wrote:
>>
>> At 11:20 22/3/01 -0500, Geir Magnusson Jr. wrote:
>> >
>> >Why wouldn't the import be allowed? That's one of the reasons for
>> >commons : to provide a place to collaborate across projects...
>>
>> Go back to the original discussion. Essentially all components should not
>> rely on external frameworks but should use the JavaBeans style standards.
>> Any code that makes it into commons is either free of the framework or
>> allowed in with the assumption that it will be refactored to be free of the
>> framework.
>
>Ok. Remember the motivation is to provide software components that can
>be shared across projects. If they are tailored to one specific
>framework, they won't easily be able to work in another.
>
>If you make it more general, then I assume more people can share the
>software.
It is better to get a little reuse than none at all.
>> As a sharing mechanism between projects commons with it's centralized
>> control is bound to fail - but then again you know my opinion on that.
>> Decentralizng control was one of the things that could of made it work
>> combined with cjan. Oh well...
>
>What centralized control do you keep seeing here?
rules & regulations etc that seem to pop up. Trying to standardise on
things that do not directly facilitate sharing. From the comical code
standards to the somewhat disturbing fact that people who know nothing
about a component and have nothing to do with it get to control it's fate.
Building high-picket fences is not a good way to share.
So far it seems you have turned away the turbine, avalon, tomcat and cocoon
developers. Presumably this will trickle down to projects like jetspeed. In
the end you have ended up creating just another tribe - just what we need ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
>
> At 11:20 22/3/01 -0500, Geir Magnusson Jr. wrote:
> >
> >Why wouldn't the import be allowed? That's one of the reasons for
> >commons : to provide a place to collaborate across projects...
>
> Go back to the original discussion. Essentially all components should not
> rely on external frameworks but should use the JavaBeans style standards.
> Any code that makes it into commons is either free of the framework or
> allowed in with the assumption that it will be refactored to be free of the
> framework.
Ok. Remember the motivation is to provide software components that can
be shared across projects. If they are tailored to one specific
framework, they won't easily be able to work in another.
If you make it more general, then I assume more people can share the
software.
> As a sharing mechanism between projects commons with it's centralized
> control is bound to fail - but then again you know my opinion on that.
> Decentralizng control was one of the things that could of made it work
> combined with cjan. Oh well...
What centralized control do you keep seeing here?
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Peter Donald <do...@apache.org>.
At 11:20 22/3/01 -0500, Geir Magnusson Jr. wrote:
>Peter Donald wrote:
>> > Jon Stevens :
>> > >For #2: It certainly could start in the Commons.
>>
>> No it couldn't from what I understand. Commons won't allow imports directly
>> from turbine/avalon and to try to do such a complex system generic from
>> start may be a bit of a PITA at this stage. Especially when both
>> turbine/avalon already offer a lot of support.
>
>Why wouldn't the import be allowed? That's one of the reasons for
>commons : to provide a place to collaborate across projects...
Go back to the original discussion. Essentially all components should not
rely on external frameworks but should use the JavaBeans style standards.
Any code that makes it into commons is either free of the framework or
allowed in with the assumption that it will be refactored to be free of the
framework.
As a sharing mechanism between projects commons with it's centralized
control is bound to fail - but then again you know my opinion on that.
Decentralizng control was one of the things that could of made it work
combined with cjan. Oh well...
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: New Subprojects
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
> From: gmj@mta4.srv.hcvlny.cv.net [mailto:gmj@mta4.srv.hcvlny.cv.net]On
> Behalf Of Geir Magnusson Jr.
>
> It also functions simply as a place to work - what goes on in the
> 'sandbox' doesn't have to be an Official Component (tm).
>
Sure enough, I guess.
Conor
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Conor MacNeill wrote:
>
> > From: gmj@mta8.srv.hcvlny.cv.net [mailto:gmj@mta8.srv.hcvlny.cv.net]On
> > Behalf Of Geir Magnusson Jr.
> > Sent: Friday, 23 March 2001 3:20 PM
> > To: general@jakarta.apache.org
> > Subject: Re: New Subprojects
> >
> >
> > Peter Donald wrote:
> > > > Jon Stevens :
> > > > >For #2: It certainly could start in the Commons.
> > >
> > > No it couldn't from what I understand. Commons won't allow
> > imports directly
> > > from turbine/avalon and to try to do such a complex system generic from
> > > start may be a bit of a PITA at this stage. Especially when both
> > > turbine/avalon already offer a lot of support.
> >
> > Why wouldn't the import be allowed? That's one of the reasons for
> > commons : to provide a place to collaborate across projects...
> >
>
> I guess it would depend on their level of coupling, wouldn't it. It is the
> difference between a framework and a collection of common utility classes.
> When you import framework classes, often it seems to be viral. To use that
> one class you end up importing quite a few other supporting classes. That is
> what makes the Commons a difficult project, there is often a natural desire
> to make it into a framework. The alternative may be a lot of "insulating"
> interfaces to allow the components to be plugged into a system without the
> supporting framework.
It also functions simply as a place to work - what goes on in the
'sandbox' doesn't have to be an Official Component (tm).
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Ted Husted <hu...@apache.org>.
Jon Stevens wrote:
> I can't wait to see what it will be like to configure all these Commons
> components and how many .xml files I will have to edit or how much
> configuration code I will have to write to make it work...
The subtext of the project is definitely "how can we create independent
packages that can be a seamless part of larger products". That's no
small task, but I don't believe Jakarta should shirk from a challenge
;-)
There does seem to be an obnoxious number of guidelines, but most are
really just best practices statements, like:
"8. Packages are encouraged to either use JavaBeans as core objects, a
JavaBean-style API, or to provide an optional JavaBean wrapper."
and
"9. External configuration files are discouraged, but if required, XML
format files are preferred for configuration options."
In practice, I think most of the packages will rely on (8), and then use
(9) for test programs.
A larger product would read configuration parameters from its own
configuration file, and then use (8) to setup the package. Which is
probably very close to whatever a product is doing now.
Once we have some code out the door, the Guidelines section of the
Charter should definitely be refactored. Right now they are a
hodge-podge of requirements, best practices, and actual voting
guidelines. But we wanted to move things along.
I am aware of at least three serious Commons proposals now in the works;
check-ins are imminent.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Peter Donald <do...@apache.org>.
yer well whatever. Illusions can be grand, I guess reality you will have to
learn through error. Good luck.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
>
> At 08:33 23/3/01 -0500, Geir Magnusson Jr. wrote:
> >> >However, this is a really good point and a discussion we should have in
> >> >Commons-land. Please come and join if interested.
> >>
> >> yes and after that you really should standardize on logging. Oh and then
> >> standardize on lifecycle because thats important too.
> >
> >Not really sure a bean utility library/component will need lifecycle and
> >logging, nor configuration for that matter
>
> I am not even sure how to answer this? I am not sure if you are serious or
> not.
No, I wasn't. You don't worry about logging issues for
'StringTokenizer', for example...
> >A Database Connection Pool is another story, but we can look a the
> >17,000 or so implementations already in Jakarta and find the best
> >practice, and then punt and use log4j :)
>
> Adopt log4j, block avalon/james/cocoon from using component and presumably
> taglib/struts when they adopt the J2EE standard. Way to achieve sharing !
I wasn't serious there either.
However, if you've decided that you aren't going to participate in
Commons, or at least give advice and participate in these kinds of
discussions that you are *clearly* interested in, then I won't be
surprised if things aren't out-of-the-box compatible with Avalon.
This isn't supposed to be another monolithic cabal.
> >> ! How long do you think before my final prediction bears true? If already
> >> you are talking about "standardisation" when that was explicitly one of the
> >> non-goals then ...
> >
> >With this kind of FUD, you should have been in software marketing :)
>
> Whats the FUD about it? One of the non-goals was to not devolve into a
> framework. For any semi-complex problem domain you need some support
> (unless you invent your own for that component). And if you have 50
> components with 50 different sets of internal frameworks then...
What FUD? For a 3 day old project that just got approved and is working
to get code contributions and projects started, that is trying to smooth
out some wrinkles in an organization that is a slight departure from the
current Jakarta convention, you have been pretty vocal in declaring the
thing a total failure because of the lurking, dreaded 'standardisation'
issues, for example.
I imagine some of the 'components' will be real basic simple stuff, not
requiring a 'framework'. I mean, what kind of framework do you need
around collections classes?
Jason has been working hard on an improved Properties-like class
that is used in Velocity and Turbine, and we were talking about that as
a proposal. Need logging?
And yes, some stuff might be big enough where these concerns about the
framework issues *are* valid, and then we have to work that out. I
don't think it's right to just declare defeat and go home, though.
> >I wasn't suggesting that we should *standardize* on anything, but rather
> >*discuss* how something like this can be realized since it appears to be
> >an important issue if we want to succeed in our goal
>
> You mean discuss a strategy that components should conform to so as to
> interact with other frameworks? ... And if components don't implement this
> strategy (aka standard) do they go straight to jail without passing go and
> without collecting $200?
No. Let me see what I said exactly :
"My better judgement tells me to dare not suggest how getting a common
configuration pattern for the components might be realized, as I am sure
it will bring howls of derision and scorn regarding central control and
big brother.
However, this is a really good point and a discussion we should have in
Commons-land. Please come and join if interested."
I think all I said was that I noted that the issue is valid, and we
should discuss them in Commons-land. I think that you are reading too
much into this...
I don't want a large set of rules either...
> >which is sharable
> >components, and a place for cross-project collaboration.
>
> If you honestly wanted to achieve sharing you wouldn't have turned off so
> many projects.
How did we turn them off in 3 days of no activity? :) Yesterday, you
declared Commons off limits to everything under the sun, Jon believed
you, and now you claim it as reality?
Declare me to be a millionaire, please...
>
> >There seem to be *plenty* of things that are standardized and
> >successful. The java API, for example. (Can you imagine if we all had
> >to roll our own 'int'?) Household electricity. The alchoholic content
> >of beer...
>
> So you are after standardisation (aka framework) - I see. Glad we cleared
> that up.
Why do you define standardaisation == framework ? Is the line voltage
of house power a 'framework'?
And yes - some standardization and conformance is good. Of the top of
my head :
1) The primary language for development is Java, but not a requirement,
because I am sure there are pieces like the tomcat connectors for apache
et al that need some C/C++/X support.
2) When you release under the Commons project, have a complete jar of
the release available for download.
3) The components must conform to the charters set up by the Jakarta
project and the ASF. (Why else are we here?)
4) The code will be released under the Apache Software license. Ibid.
Disagree with any of this yet? Does any of these suggest a framwork
like Avalon is? (or isn't?) But it is Big Brother setting basic
standards...
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 24 Mar 2001, Peter Donald wrote:
> You mean discuss a strategy that components should conform to so as to
> interact with other frameworks? ... And if components don't implement this
> strategy (aka standard) do they go straight to jail without passing go and
> without collecting $200?
>
If we did things that way, you'd be right about likelihood of failure --
but that is not at all what we're wanting to do.
Configuration and lifecycle are issues for the application (or the
framework within which the application is being created), not for the
component. All the component needs to do is expose its configurable
options as JavaBeans properties.
Now, when an application developer considers using such a reusable
component, he or she can compare the integration cost (adapt the
component's configuration/lifecycle/logging/etc) to the redevelop cost
(write it myself) and make a rational "make or buy" decision.
Imposing configuration or lifecycle design patterns *inside* a component
simply increases the potential integration cost to the extent that the
design pattern inside the component does not match the design pattern of
the framework chosen for the app.
For example, Turbine and Velocity like to configure from properties files
(among other options). Struts, Tomcat, and many other apps like XML
config files instead. They can happily share components that make *no*
assumptions one way or the other about how config data is stored. Trying
to use a component that likes one style in an app that uses the other is
much more painful.
You're perfectly correct in saying that it is hard to build good reusable
components. I don't see that as a reason not to try.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Peter Donald <do...@apache.org>.
At 08:33 23/3/01 -0500, Geir Magnusson Jr. wrote:
>> >However, this is a really good point and a discussion we should have in
>> >Commons-land. Please come and join if interested.
>>
>> yes and after that you really should standardize on logging. Oh and then
>> standardize on lifecycle because thats important too.
>
>Not really sure a bean utility library/component will need lifecycle and
>logging, nor configuration for that matter
I am not even sure how to answer this? I am not sure if you are serious or
not.
>A Database Connection Pool is another story, but we can look a the
>17,000 or so implementations already in Jakarta and find the best
>practice, and then punt and use log4j :)
Adopt log4j, block avalon/james/cocoon from using component and presumably
taglib/struts when they adopt the J2EE standard. Way to achieve sharing !
>> ! How long do you think before my final prediction bears true? If already
>> you are talking about "standardisation" when that was explicitly one of the
>> non-goals then ...
>
>With this kind of FUD, you should have been in software marketing :)
Whats the FUD about it? One of the non-goals was to not devolve into a
framework. For any semi-complex problem domain you need some support
(unless you invent your own for that component). And if you have 50
components with 50 different sets of internal frameworks then...
>I wasn't suggesting that we should *standardize* on anything, but rather
>*discuss* how something like this can be realized since it appears to be
>an important issue if we want to succeed in our goal
You mean discuss a strategy that components should conform to so as to
interact with other frameworks? ... And if components don't implement this
strategy (aka standard) do they go straight to jail without passing go and
without collecting $200?
>which is sharable
>components, and a place for cross-project collaboration.
If you honestly wanted to achieve sharing you wouldn't have turned off so
many projects.
>There seem to be *plenty* of things that are standardized and
>successful. The java API, for example. (Can you imagine if we all had
>to roll our own 'int'?) Household electricity. The alchoholic content
>of beer...
So you are after standardisation (aka framework) - I see. Glad we cleared
that up.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
>
> At 07:59 23/3/01 -0500, Geir Magnusson Jr. wrote:
> >Alex Fernández wrote:
> >> So, in a word, we don't need components that integrate with each other;
> >> we need components that need no integration at all. Perhaps we would be
> >> better off with a framework; but that's not what we think.
> >
> >My better judgement tells me to dare not suggest how getting a common
> >configuration pattern for the components might be realized, as I am sure
> >it will bring howls of derision and scorn regarding central control and
> >big brother.
If my stock market guesses were only as accurate.... this one came true
in about 12 seconds...
> >
> >However, this is a really good point and a discussion we should have in
> >Commons-land. Please come and join if interested.
>
> yes and after that you really should standardize on logging. Oh and then
> standardize on lifecycle because thats important too.
Not really sure a bean utility library/component will need lifecycle and
logging, nor configuration for that matter, but hey!, if you feel
strongly about it, come participate.
A Database Connection Pool is another story, but we can look a the
17,000 or so implementations already in Jakarta and find the best
practice, and then punt and use log4j :)
> Wait you have Avalon
What is Avalon again? Framework? independant components? Framework of
independant components? Independant framework of components?
Componentized framework independance?
> ! How long do you think before my final prediction bears true? If already
> you are talking about "standardisation" when that was explicitly one of the
> non-goals then ...
With this kind of FUD, you should have been in software marketing :)
I wasn't suggesting that we should *standardize* on anything, but rather
*discuss* how something like this can be realized since it appears to be
an important issue if we want to succeed in our goal, which is sharable
components, and a place for cross-project collaboration.
I am not interested in forcing things down anyones throat. I tend to
want to do my own thing most of the time as well, but sometimes, just
sometimes, it's good to conform if it leads to a greater good.
There seem to be *plenty* of things that are standardized and
successful. The java API, for example. (Can you imagine if we all had
to roll our own 'int'?) Household electricity. The alchoholic content
of beer...
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Ted Husted <hu...@apache.org>.
Peter Donald wrote:
> yes and after that you really should standardize on logging. Oh and then
> standardize on lifecycle because thats important too. Wait you have Avalon
> ! How long do you think before my final prediction bears true? If already
> you are talking about "standardisation" when that was explicitly one of the
> non-goals then ...
Many things were discussed, Peter, including suggestions from people who
are not part of the Commons right now, but the only "standardisation"
that made it into the charter is:
"All necessary dependencies must be recorded in the MANIFEST.MF file of
the package JAR, in the manner recommended in the JDK 1.3 documentation
describing 'system extensions'. "
We have a number of "best practices" guidelines, but that is the Jakarta
trend now. Witness the directory layout discussions.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Peter Donald <do...@apache.org>.
At 07:59 23/3/01 -0500, Geir Magnusson Jr. wrote:
>Alex Fernández wrote:
>>
>> Jon Stevens wrote:
>>
>> > I can't wait to see what it will be like to configure all these Commons
>> > components and how many .xml files I will have to edit or how much
>> > configuration code I will have to write to make it work...
>>
>> You're right, of course. If instead of integrating a whole framework we
>> have to configure 100 components so the pool has trace, XML, task
>> scheduling, web-admin and whatever capabilities, it isn't what we need.
>>
>> In fact, if the component configuration cannot be integrated in our
>> global configuration scheme, it will not do.
>>
>> So, in a word, we don't need components that integrate with each other;
>> we need components that need no integration at all. Perhaps we would be
>> better off with a framework; but that's not what we think.
>
>My better judgement tells me to dare not suggest how getting a common
>configuration pattern for the components might be realized, as I am sure
>it will bring howls of derision and scorn regarding central control and
>big brother.
>
>However, this is a really good point and a discussion we should have in
>Commons-land. Please come and join if interested.
yes and after that you really should standardize on logging. Oh and then
standardize on lifecycle because thats important too. Wait you have Avalon
! How long do you think before my final prediction bears true? If already
you are talking about "standardisation" when that was explicitly one of the
non-goals then ...
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Alex Fernández wrote:
>
> Jon Stevens wrote:
>
> > I can't wait to see what it will be like to configure all these Commons
> > components and how many .xml files I will have to edit or how much
> > configuration code I will have to write to make it work...
>
> You're right, of course. If instead of integrating a whole framework we
> have to configure 100 components so the pool has trace, XML, task
> scheduling, web-admin and whatever capabilities, it isn't what we need.
>
> In fact, if the component configuration cannot be integrated in our
> global configuration scheme, it will not do.
>
> So, in a word, we don't need components that integrate with each other;
> we need components that need no integration at all. Perhaps we would be
> better off with a framework; but that's not what we think.
My better judgement tells me to dare not suggest how getting a common
configuration pattern for the components might be realized, as I am sure
it will bring howls of derision and scorn regarding central control and
big brother.
However, this is a really good point and a discussion we should have in
Commons-land. Please come and join if interested.
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Gunnar R|nning <gu...@candleweb.no>.
Alex Fernández <af...@tid.es> writes:
>
> In fact, if the component configuration cannot be integrated in our
> global configuration scheme, it will not do.
My concern as well.
> So, in a word, we don't need components that integrate with each other;
> we need components that need no integration at all. Perhaps we would be
> better off with a framework; but that's not what we think.
>
> I'm only talking about our particular needs (one small project within
> Telefonica I+D), but I feel it's not so uncommon.
I don't this is uncommon, I've been there alot of times myself. A framework
is good, but loose coupling and reusability of components are well worth
pursuing as well. The point is to design your components so they may
integrate with any framework and put the framework specific code in the
framework itself.
regards,
Gunnar
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Alex Fernández <af...@tid.es>.
Hi Jon!
Jon Stevens wrote:
> > we use
> > standard interfaces when they exist, otherwise we define one.
>
> What is standard?
>
> <http://jakarta.apache.org/velocity/ymtd/ymtd-implementation.html>
A 'standard' should be one of these, according to the American Heritage
Dictionary:
1.Serving as or conforming to a standard of measurement or value.
2.Widely recognized as a model of authority or excellence: a
standard reference work.
3.Acceptable but of less than top quality: a standard grade of beef.
4.Normal, familiar, or usual: the standard excuse.
5.Commonly used or supplied: standard car equipment.
Definitely it's not 1, I'd like it to be 2 but I doubt it, and 3 is not
what I wanted to say, although it's what you seem to think about some of
them :)
4 would be close, and 5 is right about it: commonly used or supplied. If
you're planning to use XML, you have better use SAX or DOM, since about
every package provides both interfaces -- we're not Microsoft, so we
cannot define our own.
Notice that this definition does not specify where the standard thing
comes from: a consensus from a broad userbase, an authority, a powerful
corporation, or whatever -- it's just commonly used or supplied.
Un saludo,
Alex.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Jon Stevens <jo...@latchkey.com>.
on 3/23/01 2:42 AM, "Alex Fernández" <af...@tid.es> wrote:
> we use
> standard interfaces when they exist, otherwise we define one.
What is standard?
<http://jakarta.apache.org/velocity/ymtd/ymtd-implementation.html>
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Alex Fernández <af...@tid.es>.
Hi folks!
Jon Stevens wrote:
> Maybe one day people will realize that it is significantly easier to just
> download the 400k turbine.jar and link against that than it is to spend a
> huge amount of effort decoupling and interfacing everything to oblivion.
For us, it's not about easy or difficult. We have a project, we need a
trace component, so we take the one we find easiest to integrate. In
fact, we'll take care of isolating it behind an interface, since there
seems to be no standard for traces.
The same is valid for a JDBC pool, an XML parser and the rest -- we use
standard interfaces when they exist, otherwise we define one.
> I can't wait to see what it will be like to configure all these Commons
> components and how many .xml files I will have to edit or how much
> configuration code I will have to write to make it work...
You're right, of course. If instead of integrating a whole framework we
have to configure 100 components so the pool has trace, XML, task
scheduling, web-admin and whatever capabilities, it isn't what we need.
In fact, if the component configuration cannot be integrated in our
global configuration scheme, it will not do.
So, in a word, we don't need components that integrate with each other;
we need components that need no integration at all. Perhaps we would be
better off with a framework; but that's not what we think.
I'm only talking about our particular needs (one small project within
Telefonica I+D), but I feel it's not so uncommon.
Un saludo,
Alex.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Jon Stevens <jo...@latchkey.com>.
on 3/22/01 7:34 PM, "Conor MacNeill" <co...@cortexebusiness.com.au> wrote:
> That is what makes the Commons a difficult project, there is often a natural
> desire to make it into a framework.
ie: Turbine
LOL! This cracks me up...
Maybe one day people will realize that it is significantly easier to just
download the 400k turbine.jar and link against that than it is to spend a
huge amount of effort decoupling and interfacing everything to oblivion.
I can't wait to see what it will be like to configure all these Commons
components and how many .xml files I will have to edit or how much
configuration code I will have to write to make it work...
Joy...
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: New Subprojects
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
> From: gmj@mta8.srv.hcvlny.cv.net [mailto:gmj@mta8.srv.hcvlny.cv.net]On
> Behalf Of Geir Magnusson Jr.
> Sent: Friday, 23 March 2001 3:20 PM
> To: general@jakarta.apache.org
> Subject: Re: New Subprojects
>
>
> Peter Donald wrote:
> > > Jon Stevens :
> > > >For #2: It certainly could start in the Commons.
> >
> > No it couldn't from what I understand. Commons won't allow
> imports directly
> > from turbine/avalon and to try to do such a complex system generic from
> > start may be a bit of a PITA at this stage. Especially when both
> > turbine/avalon already offer a lot of support.
>
> Why wouldn't the import be allowed? That's one of the reasons for
> commons : to provide a place to collaborate across projects...
>
I guess it would depend on their level of coupling, wouldn't it. It is the
difference between a framework and a collection of common utility classes.
When you import framework classes, often it seems to be viral. To use that
one class you end up importing quite a few other supporting classes. That is
what makes the Commons a difficult project, there is often a natural desire
to make it into a framework. The alternative may be a lot of "insulating"
interfaces to allow the components to be plugged into a system without the
supporting framework.
Conor
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Peter Donald wrote:
> > Jon Stevens :
> > >For #2: It certainly could start in the Commons.
>
> No it couldn't from what I understand. Commons won't allow imports directly
> from turbine/avalon and to try to do such a complex system generic from
> start may be a bit of a PITA at this stage. Especially when both
> turbine/avalon already offer a lot of support.
Why wouldn't the import be allowed? That's one of the reasons for
commons : to provide a place to collaborate across projects...
geir
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Jon Stevens <jo...@latchkey.com>.
on 3/22/01 10:51 PM, "Craig R. McClanahan" <cr...@apache.org> wrote:
> So, are you planning to propose these as reusable components after
> jumping up and down about sharing?
I have been jumping up and down about sharing for years now...suddenly you
have decided to start listening AND participating instead of just saying you
would?
Personally, I'm tired of jumping up and down. You can jump for a while and I
will watch in amusement...
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 22 Mar 2001, Jon Stevens wrote:
> on 3/22/01 7:23 PM, "Peter Donald" <do...@apache.org> wrote:
>
> > No it couldn't from what I understand. Commons won't allow imports directly
> > from turbine/avalon and to try to do such a complex system generic from
> > start may be a bit of a PITA at this stage. Especially when both
> > turbine/avalon already offer a lot of support.
>
> Woah. I didn't know that about the commons. So, we can't start with existing
> code already housed on our servers? If that is the case, I see no future for
> the Commons.
>
> In fact, looking at it...
>
> <http://jakarta.apache.org/cvsweb/index.cgi/jakarta-commons/>
>
> There still isn't any code in there.
>
> All discussion and no code makes the Commons a dull boy.
>
> Guess I will just keep plugging away with the perfectly working Turbine
> Connection Pool and Scheduler Services.... :-)
>
So, are you planning to propose these as reusable components after
jumping up and down about sharing?
tick ... tick ... tick ... (showing about as much patience as Jon ever
does) ... yawn ...
Nah, I didn't think so.
:-)
> -jon
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Jon Stevens <jo...@latchkey.com>.
on 3/22/01 7:23 PM, "Peter Donald" <do...@apache.org> wrote:
> No it couldn't from what I understand. Commons won't allow imports directly
> from turbine/avalon and to try to do such a complex system generic from
> start may be a bit of a PITA at this stage. Especially when both
> turbine/avalon already offer a lot of support.
Woah. I didn't know that about the commons. So, we can't start with existing
code already housed on our servers? If that is the case, I see no future for
the Commons.
In fact, looking at it...
<http://jakarta.apache.org/cvsweb/index.cgi/jakarta-commons/>
There still isn't any code in there.
All discussion and no code makes the Commons a dull boy.
Guess I will just keep plugging away with the perfectly working Turbine
Connection Pool and Scheduler Services.... :-)
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Peter Donald <do...@apache.org>.
At 07:03 22/3/01 -0800, Jon Stevens wrote:
>on 3/22/01 2:15 PM, "James House" <ja...@medibuy.com> wrote:
>
>> Project 1: an Enterprise Job Scheduler
>> =====================================
>
>Both Avalon and Turbine offer this.
>
>> Project 2: a Workflow Engine / Process Automator
>> =====================================
>
>This is something we need as well.
>
>For #1: Taking the best parts from Avalon and Turbine and merging them into
>a Commons would be good.
>
>For #2: It certainly could start in the Commons.
No it couldn't from what I understand. Commons won't allow imports directly
from turbine/avalon and to try to do such a complex system generic from
start may be a bit of a PITA at this stage. Especially when both
turbine/avalon already offer a lot of support.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Remy Maucherat <rm...@home.com>.
> James House wrote:
> >
> > [...]
> >
> > Project 2: a Workflow Engine / Process Automator
> > =====================================
> > Description:
> >
> > An engine for doing Workflow and Process Automation within or without a
J2EE
> > application server.
> >
> > Desired Features:
> >
> > * I haven't put much thought into this yet, but I feel this is a real
need
> > in the open source world unless someone can tell me of an existing one?
> >
> > In case you're not sure what I'm referring to, here's a product of BEA's
> > that is similar to what I'm envisioning:
> > http://www.bea.com/products/weblogic/integrator/datasheet.shtml
> >
> > Anyone interested in participating in either of these please contact me:
> > james@interobjective.com
>
> I think both projects sounds great and targets what you would want/need in
a bigger project.
> Having worked with products such as Infooffice, StoryServer, Interwoven I
have allot of input
> on how to make the second project and I would also like it to target
content management since
> the CMS products are generally a piece of shit that costs 80.000$ !! (i.e.
Interwoven).
>
> I'd love to get involved with both projects in which ever OpenSource
umbrella they end up
> under, and would like to see them under Jakarta.
I'm interested in a project like (2) for Slide, for the reasons mentioned by
Bip and others. Of course, since it's for embedding it into another product,
I don't need all the functionality of a generic workflow engine.
However, I have doubts that that kind of project can be started with only
general ideas. I think such a proposal should be made with a prototype
codebase and / or detailed design ideas.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: New Subprojects
Posted by James House <ho...@trilobyte.net>.
>I think both projects sounds great and targets what you would want/need in
a bigger project.
>Having worked with products such as Infooffice, StoryServer, Interwoven I
have allot of input
>on how to make the second project and I would also like it to target
content management since
>the CMS products are generally a piece of shit that costs 80.000$ !! (i.e.
Interwoven).
Yeah... I've worked with a few products myself, and had the same feeling:
how can they charge this much $$ for this crap! Maybe we could build
something that forces them to build something worth their price tag.
>I'd love to get involved with both projects in which ever OpenSource
umbrella they end up
>under, and would like to see them under Jakarta.
>
> Regards, Bip
Great! -- I'd be happy to let you 'lead' the workflow/process automator
project... one person can only do so much!
James
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Bip Thelin <bi...@razorfish.com>.
See comments below.
James House wrote:
>
> [...]
>
> Project 2: a Workflow Engine / Process Automator
> =====================================
> Description:
>
> An engine for doing Workflow and Process Automation within or without a J2EE
> application server.
>
> Desired Features:
>
> * I haven't put much thought into this yet, but I feel this is a real need
> in the open source world unless someone can tell me of an existing one?
>
> In case you're not sure what I'm referring to, here's a product of BEA's
> that is similar to what I'm envisioning:
> http://www.bea.com/products/weblogic/integrator/datasheet.shtml
>
> Anyone interested in participating in either of these please contact me:
> james@interobjective.com
I think both projects sounds great and targets what you would want/need in a bigger project.
Having worked with products such as Infooffice, StoryServer, Interwoven I have allot of input
on how to make the second project and I would also like it to target content management since
the CMS products are generally a piece of shit that costs 80.000$ !! (i.e. Interwoven).
I'd love to get involved with both projects in which ever OpenSource umbrella they end up
under, and would like to see them under Jakarta.
Regards, Bip
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: New Subprojects
Posted by Peter Donald <do...@apache.org>.
At 10:06 22/3/01 -0700, James House wrote:
>>> Project 1: an Enterprise Job Scheduler
>>> =====================================
>>For #1: Taking the best parts from Avalon and Turbine and merging them into
>>a Commons would be good.
>>
>
>I have not looked far into the Schedulers in Avalon or Turbine - but I think
>that they currently fall quite short of the features features I listed. I
>also don't beleive they are 'organized' in a way that easily fators into
>what I want to build (not to say they wouldn't offer a wealth of code to
>start out with).
Well the parts in Avalon CVS are the "base" of my cron job server that did
most of what you wanted ;)
>From memory the other blocks I created were
PersistentJobStore - stores job definitions and scheduling
JobDispatcher - ie used the job defintions to create list of ant tasks and
execute them
SubjectManager - ie had the subjects/principles and their associated
permissions
CronScheduler - Manager all the rest of the components
Except for SubjectManager (which was an absolute PITA) all the rest are
relatively easy to implement. We had both a DB based PersistentJobStore and
a file based PersistentJobStore.
The only reason it is not free software/opensource at the moment is because
(a) it relies on a very very ugly fork of ant code (enough that I am
ashamed to call it my own ;])
(b) I don't have sole copyright on most of it ;(
As soon as the task engine for ant2.0 is complete I will rebuild it again
though ;) It is largely comparable to fluxs server but it did not have some
of the more complex stuff (they had automatic notification/events for
certain cron events IIRC). Any it will be hosted in Avalon/Phoenix ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
James House wrote:
>
> Maybe I'm still unsure of the purpose of "the commons" but, do you really
> want something as huge as a process automator in there? -- We're talking
> about something on the scale of a full-blown EJB container here. It's not
> something somebody would want packaged along with a handy 'Collections'
> library.
That's very true - but one of the motivations of Commons was to be a
place for open collaboration, sharing and, while some hate the word,
'experimentation'. It would be a place for multiple people to work, and
then as things shape up, you have a better basis for deciding where such
a beastie will live as a 'formal' project.
You could also try it under the asupices of Avalon, Turbine, Struts
too...
gier
--
Geir Magnusson Jr. geirm@optonline.net
Developing for the web? See http://jakarta.apache.org/velocity/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: New Subprojects
Posted by James House <ho...@trilobyte.net>.
>> Project 1: an Enterprise Job Scheduler
>> =====================================
>
>> Project 2: a Workflow Engine / Process Automator
>> =====================================
>
>This is something we need as well.
>
>For #1: Taking the best parts from Avalon and Turbine and merging them into
>a Commons would be good.
>
I have not looked far into the Schedulers in Avalon or Turbine - but I think
that they currently fall quite short of the features features I listed. I
also don't beleive they are 'organized' in a way that easily fators into
what I want to build (not to say they wouldn't offer a wealth of code to
start out with).
I'm looking to build something that can act much the same way as a JMS
provider, or an EJB container, but also can just be used in a simpler form
within stand-alone applications.
Flux (http://www.simscomputing.com) is similar to what I had in mind.
Perhaps I better get to drawing up my plans.
>For #2: It certainly could start in the Commons.
Maybe I'm still unsure of the purpose of "the commons" but, do you really
want something as huge as a process automator in there? -- We're talking
about something on the scale of a full-blown EJB container here. It's not
something somebody would want packaged along with a handy 'Collections'
library.
I really am open to whatever - I personally just think these projects (and
especially #2) are too big, and to likely to be used on their own, to want
them to be part of a framework.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: New Subprojects
Posted by Jon Stevens <jo...@latchkey.com>.
on 3/22/01 2:15 PM, "James House" <ja...@medibuy.com> wrote:
> Project 1: an Enterprise Job Scheduler
> =====================================
Both Avalon and Turbine offer this.
> Project 2: a Workflow Engine / Process Automator
> =====================================
This is something we need as well.
For #1: Taking the best parts from Avalon and Turbine and merging them into
a Commons would be good.
For #2: It certainly could start in the Commons.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org