When it comes time to do this clean up and restructure I think we
should change the base groupId to org.apache.geronimo.server and
the root artifactId to server to reflect its new location in svn
(for consistency) and to allow a clean namespace in the repo between
the different G
Any rough idea what that car-organized tree might look like?
--jason
On Sep 11, 2006, at 3:21 PM, David Jencks wrote:
So, while cleaning up dependencies a bit to try to make separate
transaction and connector-deployer configs, I remembered that we
have this problem that right now the
Please help me try to understand this -
Will our jars will be taken/seen/used outside the Geronimo context ?
If they are, then I agree that geronimo-activation-1.2.jar is more
meaningful than a simple activation-1.2.jar. The latter also gives
scope for name conflicts.
But if our jars are always
So, while cleaning up dependencies a bit to try to make separate
transaction and connector-deployer configs, I remembered that we have
this problem that right now the maven dependencies between modules
(jar files) are all to other geronimo jar files, whereas the geronimo
dependencies
--- David Jencks [EMAIL PROTECTED] wrote:
So, while cleaning up dependencies a bit to try to make separate
transaction and connector-deployer configs, I remembered that we have
this problem that right now the maven dependencies between modules
(jar files) are all to other geronimo jar
On 9/7/06, David Jencks [EMAIL PROTECTED] wrote:
On Sep 5, 2006, at 7:28 PM, Dain Sundstrom wrote:
BTW I do think we should rename the dirs to match the maven
standard geronimo-foo standard.
I completely agree
-dain
On Sep 5, 2006, at 2:49 PM, Jason Dillon wrote:
Fine with me.
The
Is this a must have or a nice to have? Everything in the tree is already geronimo and nicely fits
in a geronimo dir in the maven repo. Can someone from Maven enlighten me as to why the redundancy
is necessary and how redundancy is a good thing to be redundant. Not to repeat myself, but I
Matt, I have already explained why... at least twice :-P
If we want to remove the geronimo- prefix, then lets rename the
artifacts... which I think should be done anyways when the modules
are split up into smaller groups.
For example, if we have a components/ tree, which groups optional
And here you go again... or do you need this in triplicate?
:-P
* * *
Matt, I have already explained why... at least twice :-P
If we want to remove the geronimo- prefix, then lets rename the
artifacts... which I think should be done anyways when the modules
are split up into smaller
Ok, point taken on my pedantic and redundant rant. Of course I got sidetracked.
I like the structuring a lot. I think there are a number of different ways to organize it and if
you ask my wife I'm not one to be giving organizational input ;-) One thing that makes sense to me
is organization
Hehehehehe...no, that'll be fine :) I get it.
Jason Dillon wrote:
And here you go again... or do you need this in triplicate?
:-P
* * *
Matt, I have already explained why... at least twice :-P
If we want to remove the geronimo- prefix, then lets rename the
artifacts... which I think
Matt Hogstrom wrote:
System seems to made up of the core elements of Geronimo. Are we
missing a /distributions or /server element? It would be awesome to
only have to change the version of the distributions in one place.
I had recommended we rename /system to /server as I think that most
Matt, think of the maven directory layout like ruby on rails.
Following the convention makes your life easy.
-dain
On Sep 5, 2006, at 11:00 PM, Matt Hogstrom wrote:
Is this a must have or a nice to have? Everything in the tree is
already geronimo and nicely fits in a geronimo dir in the
I understand your point and I agree that making our life easier is the right thing. Just asking the
questions. I think it looks odd and clunky and would prefer something cleaner. I am just one
little voice in a sea of opinions :)
Dain Sundstrom wrote:
Matt, think of the maven directory
I'm assuming everything is not geronimo- ... that might be from the department
of redundancy department.
Jason Dillon wrote:
So, I've mentioned a few times before that we should start thinking
about how to split up modules in trunk into a few smaller chunks. I
took a few minutes and took a
The problem with not keeping the geronimo- prefix is that all jars will end up as activemq-1.2.jar activation-1.2.jarIt will be highly confusing.The other solution is to break the directory name = artifactId rule, which is imho
a bad idea.On 9/5/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
I'm
I understand your point. I guess I'm conflicted at this point as it seems like Geronimo is becoming
a Maven project :-) If the underlying tool is causing such fundamental changes to the way the
project is structured, named, etc. is the tool flexible enough?
I don't mean to start a rant or a
Right, the pom can and should contain the geronimo-prefix but why is it necessary for the directory structure to match? With all the file length problems, I also this this is unnecessary and redundant.On Sep 5, 2006, at 3:36 PM, Guillaume Nodet wrote:The problem with not keeping the geronimo-
I am sure that some of these names will change...
But the directory name should be the same as the artifactId... so
that its easy to see where the source for artifacts come from, and
because some maven plugins that work on sets of modules make that
assumption (like site plugin for example)
On Sep 5, 2006, at 12:56 PM, Matt Hogstrom wrote:
I understand your point. I guess I'm conflicted at this point as
it seems like Geronimo is becoming a Maven project :-) If the
underlying tool is causing such fundamental changes to the way the
project is structured, named, etc. is the
The directory should match because: * it makes it easier to find out which module produces which artifact * plugins that operate on hierarchies of modules make use of the parent directory name when generating output. if they don't match, then you end up needing to configure each module, which is
Please don't get mad at me, but I'd like to move a bit slower on more
classification inside of the server module. I'd like to pull
transaction and connector out to independently versioned modules and
then see if the tree still feels crowded.
-dain
On Sep 5, 2006, at 2:27 PM, Jason Dillon
Ya, this is one of the main reasons.We don't have to have geronimo-* in infront of everything, for example our activemq integration might be in:components/ activemq-component/This, plus the groupId makes it clear enough... but we should not call the module activemq. * * *Its sad and a little
On 9/5/06, Jason Dillon [EMAIL PROTECTED] wrote:
I am sure that some of these names will change...
But the directory name should be the same as the artifactId... so
that its easy to see where the source for artifacts come from, and
because some maven plugins that work on sets of modules make
Fine with me.
The tree is still in need of reorganization even after those modules
are gone.
--jason
On Sep 5, 2006, at 2:42 PM, Dain Sundstrom wrote:
Please don't get mad at me, but I'd like to move a bit slower on
more classification inside of the server module. I'd like to pull
BTW I do think we should rename the dirs to match the maven standard
geronimo-foo standard.
-dain
On Sep 5, 2006, at 2:49 PM, Jason Dillon wrote:
Fine with me.
The tree is still in need of reorganization even after those
modules are gone.
--jason
On Sep 5, 2006, at 2:42 PM, Dain
I guess the rest of the proposal looks good... not sure that the
build dependencies fit into those boxes as they are laid out though
(and they probably don't fit into my example either).
I think we may have to stage this... probably can create framework/
and move a few modules in there
On Aug 31, 2006, at 1:31 PM, Joe Bohn wrote:
Ok ... take a deep breath.
This proposal was *not* just to work around windows. It was to
offer what I thought were constructive ideas and avoid exasperating
a known problem unnecessarily.
Yes, I understand.
I understand your hesitation to
I'd like to propose that we keep things simple and eliminate redundancy
where possible. I'd also like to keep things as brief as possible to
prevent current or future issues with the windows pathlength issue. I
don't think the proposed changes will cause immediate problems but I'd
like to
+1 on this proposal
On 8/31/06, Joe Bohn [EMAIL PROTECTED] wrote:
I'd like to propose that we keep things simple and eliminate redundancy
where possible. I'd also like to keep things as brief as possible to
prevent current or future issues with the windows pathlength issue. I
don't think the
On Aug 31, 2006, at 7:26 AM, Joe Bohn wrote:
I'd like to propose that we keep things simple and eliminate
redundancy where possible. I'd also like to keep things as brief
as possible to prevent current or future issues with the windows
pathlength issue. I don't think the proposed changes
wow, nice rant ;)
To be correct it is an API problem in windows that path names are restricted
to 254 or 260 chars (Win2k), it's not an NTFS problem.
You can create pathes with more characters when using UNC names. The limitation
should be 32767 chars.
If you have already a base path for the
Ok ... take a deep breath.
This proposal was *not* just to work around windows. It was to offer
what I thought were constructive ideas and avoid exasperating a known
problem unnecessarily.
I understand your hesitation to bundle the builders and deployers
together (which is why I had a note
I had thought about calling that module 'extentions' though seemed
odd, since out extention mechanism is called plugins.
I had also though about a 'components' tree, for optional stuff that
can plugin, but not core to the server.
--jason
On Aug 28, 2006, at 8:02 AM, Paul McMahan wrote:
Jason, the distinction between framework and system might be
unclear to a novice. Something like bootstrap and system might be
clearer. Also, I think of plugin as a packaging/distribution
mechanism instead of a statement of functionality so I would call that
directory something like ext and put
So, I've mentioned a few times before that we should start thinking
about how to split up modules in trunk into a few smaller chunks. I
took a few minutes and took a crude stab at what that might look
like. This is just an example of how it might work... I did not do
any extensive
36 matches
Mail list logo
