On Aug 6, 2007, at 9:59 AM, Donald Woods wrote:
Anything more than 6 to 8 groupings could cause chaos (just like at
our current release process which takes weeks to get everything
voted and released...)
After cleanup of server to move the samples to /samples and
ApacheDS to /plugins, we
On Aug 6, 2007, at 11:12 AM, Donald Woods wrote:
Another thought (now that I had some lunch)
What if we create a builders/deployers grouping, which contained
the modules and configs needed for each builder, like -
deployers
myfaces
modules
On Aug 6, 2007, at 8:03 PM, David Blevins wrote:
On Aug 6, 2007, at 8:12 AM, David Jencks wrote:
I certainly agree with your goal but am less sure about your
proposed naming and organization. Also from looking at your list
it took me a couple minutes to figure out what is removed from
On Aug 29, 2007, at 10:12 AM, Prasad Kashyap wrote:
Scenario 1:
server/support/trunk
server/framework/trunk
server/plugins/trunk/ --- jee5, non-jee5, samples etc are
all here together.
I'm not really convinced we need to have this intermediate server
tree right now. IMO
On Aug 29, 2007, at 1:12 PM, Prasad Kashyap wrote:
2. We have to split the current build tree into support, framework,
and plugins sub-trees. Other than support and framework, everything
else should be plugins. This includes jee5, non-jee5, samples etc.
which could go in their own subtrees or
I'm trying to understand what we have discussed/decided so far. Please
let me know if my summary is on track and help me correct course.
We haven't discussed the actual maven groupIds/artifactIds/directory
names yet. So all names used in this summary are just as examples.
Summary:
I think we don't really need svn, lets just mail around patches we
make to the list and get rid of this scm crapo... too much work for
too little benifit lol
:-P
--jason
On Aug 29, 2007, at 10:12 AM, Prasad Kashyap wrote:
I'm trying to understand what we have discussed/decided so
On Aug 6, 2007, at 12:43 PM, Paul McMahan wrote:
On Aug 6, 2007, at 12:59 PM, Donald Woods wrote:
we should consider the more drastic changes, like moving the base
Admin Console support (via Pluto 1.2) out to /plugins
I really like that idea for a couple of reasons -
- it allows us to keep
On Aug 6, 2007, at 8:03 PM, David Blevins wrote:
On Aug 6, 2007, at 8:12 AM, David Jencks wrote:
I certainly agree with your goal but am less sure about your
proposed naming and organization. Also from looking at your list
it took me a couple minutes to figure out what is removed from
Hiya, I've mentioned this before... and now that we have a 2.0 branch
and trunk has moved on to 2.1 work, I think its time we really make a
decision on this and implement it.
Before, I had been thinking of keeping all of the modules in the
server/trunk tree just in better locations
I certainly agree with your goal but am less sure about your proposed
naming and organization. Also from looking at your list it took me a
couple minutes to figure out what is removed from server
I've been thinking that we could proceed by turning bits of the
server into plugins. For
Um, I just took a blind stab in the dark...
But, what I was thinking was that we have the core modules which are
the bare minimum to boot up a functional Geronimo server w/o any
JavaEE muck, then slice up the other components into plugins, though
they don't really need to be G plugins,
Anything more than 6 to 8 groupings could cause chaos (just like at our
current release process which takes weeks to get everything voted and released...)
We already have 5 groupings created -
- devtools (Eclipse, Netbeans, J2G)
- plugins (non-JEE5 required server add-ons)
- samples (should
Another thought (now that I had some lunch)
What if we create a builders/deployers grouping, which contained the modules
and configs needed for each builder, like -
deployers
myfaces
modules
geronimo-myfaces
On Aug 6, 2007, at 9:59 AM, Donald Woods wrote:
Anything more than 6 to 8 groupings could cause chaos (just like at
our current release process which takes weeks to get everything
voted and released...)
Yes, it has to be done very carefully, though if you look a Maven,
Plexus and the
I'd rather not have another level to simply separate code jars from
config jars... I think they should all live together, and if needed
we suffix the config bits with -config, so you'd have:
activemq-broker
activemq-broker-config
activemq-ra
activemq-ra-config
IMO, no need for
On Aug 6, 2007, at 12:59 PM, Donald Woods wrote:
we should consider the more drastic changes, like moving the base
Admin Console support (via Pluto 1.2) out to /plugins
I really like that idea for a couple of reasons -
- it allows us to keep the admin console that's currently at server/
On Aug 6, 2007, at 12:43 PM, Paul McMahan wrote:
On Aug 6, 2007, at 12:59 PM, Donald Woods wrote:
we should consider the more drastic changes, like moving the base
Admin Console support (via Pluto 1.2) out to /plugins
I really like that idea for a couple of reasons -
- it allows us to
On Aug 6, 2007, at 8:12 AM, David Jencks wrote:
I certainly agree with your goal but am less sure about your
proposed naming and organization. Also from looking at your list
it took me a couple minutes to figure out what is removed from
server
I've been thinking that we could proceed
19 matches
Mail list logo
