On Nov 23, 2005, at 1:58 PM, David Jencks wrote:
I've investigated this a little bit and think it might be too big
a lurch in a new direction for 1.0. Here are a few of the things
that would have to change or appear to be problems:
1. constructing the configId from groupId + artifactId +
On Nov 23, 2005, at 1:12 PM, Dain Sundstrom wrote:
On Nov 23, 2005, at 1:58 PM, David Jencks wrote:
I've investigated this a little bit and think it might be too big a
lurch in a new direction for 1.0. Here are a few of the things that
would have to change or appear to be problems:
1.
On Nov 23, 2005, at 3:27 PM, David Jencks wrote:
On Nov 23, 2005, at 1:12 PM, Dain Sundstrom wrote:
On Nov 23, 2005, at 1:58 PM, David Jencks wrote:
I've investigated this a little bit and think it might be too
big a lurch in a new direction for 1.0. Here are a few of the
things that
On Nov 23, 2005, at 4:14 PM, David Jencks wrote:
On Nov 23, 2005, at 2:02 PM, Dain Sundstrom wrote:
On Nov 23, 2005, at 3:27 PM, David Jencks wrote:
Should we change our dependency URIs to the same format? I'm
inclined to think we should. I would prefer to include the type
(car|jar)
On 11/23/05, Dain Sundstrom [EMAIL PROTECTED] wrote:
I know it will make the files much longer, but I'd prefer we drop or
deprecate support for the single line dependency declaration, which
means we require the full format:
I object to doing this. I really think most users are going to want
On Nov 23, 2005, at 3:46 PM, Aaron Mulder wrote:
On 11/23/05, Dain Sundstrom [EMAIL PROTECTED] wrote:
I know it will make the files much longer, but I'd prefer we drop or
deprecate support for the single line dependency declaration, which
means we require the full format:
I object to doing
On 11/23/05, David Jencks [EMAIL PROTECTED] wrote:
First, I think Dain is talking mostly about dependencies here. In this
case if we continue to support the short form you would write
uriyourGroup/yourArtifact/yourVersion/jar/uri
rather than
Also, we need to think about the meaning of version. You might
deploy a lot of times between designated versions of an application.
I'd prefer that we not require that the version be SNAPSHOT if you're
going to do that (because then they really are indistinguishable). It
would be nice if you
To me the biggest problem here is still backwards compatibility and
if/how we can support it. Dain suggested (privately) that we might
have a conversion table for our configids so that an old plan would
still deploy. This is possible but really ugly. I will look into just
how ugly :-) I'd
On Nov 22, 2005, at 2:51 PM, Dain Sundstrom wrote:
On Nov 22, 2005, at 1:35 PM, David Jencks wrote:
To me the biggest problem here is still backwards compatibility and
if/how we can support it. Dain suggested (privately) that we might
have a conversion table for our configids so that an
I don't understand why people are using repository and
config-store interchangeably.
My understanding of repository is that it's where third-party
libraries are stored. A URI into the repository works like maven by
convention because that's how we've chosen to lay out our repository.
But for
Aaron,
I think you have summed it up best when you used this example:
My understanding of packaged configurations is you take whatever's
in config-store/22 and zip it -- now you have a packaged
configuration or CAR and the repository was never involved. If you
want to move that to a different
On Nov 22, 2005, at 3:16 PM, Aaron Mulder wrote:
I don't understand why people are using repository and
config-store interchangeably.
Right now the config-store used in geronimo happens to not relate the
configId and the file location. I'm interested to see what happens if
I implement a
Dain Sundstrom wrote:
On Nov 22, 2005, at 1:35 PM, David Jencks wrote:
To me the biggest problem here is still backwards compatibility and
if/how we can support it. Dain suggested (privately) that we might
have a conversion table for our configids so that an old plan would
still deploy.
I assume it will be the case that the configId declaration in the file
will therefore control which repository location the CAR is installed
in -- so if you change the configId, it changes the install location.
Is that correct?
Here are my issues:
- It's a pretty significant change for the last
On Nov 17, 2005, at 11:30 PM, David Jencks wrote:
This relies on using the packaging plugin, which builds
configurations and puts them into the local maven repository. As
such, it uses the maven id as the configId: they typically look like
I have been working on assembling geronimo using the packaging and
assembly plugins. This gives us the ability to put together versions
of geronimo with different capabilities without duplication. For
instance, we now have a jetty-only and a tomcat-only version of
geronimo. To build these,
17 matches
Mail list logo
