You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Daniel F. Savarese" <df...@savarese.org> on 2004/12/19 05:13:02 UTC
Re: Jakarta Commons Structure rehashed
In message <31...@mail.gmail.com>, Henri Yandell writes:
>On Sun, 19 Dec 2004 00:00:20 +1300, Simon Kitching
><s_...@paradise.net.nz> wrote:
>> svn 1.1 (released 2004-09-29) supports "symbolic links". Perhaps that
>> would resolve the issue by allowing us to (manually) build an
>> alternative directory containing just symbolic links to the "trunk"
>> directory of each subproject? Of course whenever a new subproject was
>> created, a symbolic link would need to be manually added - but that is
>> no great problem. Possibly that could even be automated; I'm willing to
>> try to get that working.
>
>Cool. I knew such a feature was in the planning but hadn't realised it
>was out yet. I'm +1 on option A + sym-links or script depending on
>which feels best.
>
>As long as there's a simple way to check out the head of all of commons :)
I haven't read the entire thread, but if I understand what's being
discussed, checking in symbolic links won't do what you want (assuming
we're talking about ln -s symbolic links). Setting the svn:externals
property will do what I think you're talking about. For example, you
could set svn:externals in a directory to:
lang https://svn.apache.org/repos/asf/jakarta/commons/proper/lang/trunk
math https://svn.apache.org/repos/asf/jakarta/commons/proper/math/trunk
...
That way when you check out the directory, subdirectories lang, math,
etc. are created with the contents of the urls checked out.
I prefer the idea of using a script instead because it's more flexible
for doing things like checking out personalized subsets of commons.
Anyway, I may have misunderstood the intent from the get go.
I also prefer the flatter layout:
jakarta/commons/tags/
/attributes-1.0.1
/attributes-1.0.2
/beanutils-0.9.7
/sandbox/altrmi-x.x.x
...
/branches
/lang-foo
/math-bar
/trunk
/attributes
...
/sandbox
/altrmi
/amend
...
/site
...
/validator
I can't offer a reason why it's technically better because it just
amounts to personal preference. Also, I see how doing having
proper/ and sandbox/ parent trees makes certain things easier
(like generating commit message subject headers). However, it does
make it easier to check out the trunk of commons all at once. I'm
sure I missed the original discussion about this, so don't reraise the
issue on my account. It doesn't really matter anyway because layouts
can be changed after the fact if there's some compelling reason to do
so. I only wanted to convey the bit about svn:externals vis a vis
symbolic links since it caught my eye.
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Jakarta Commons Structure rehashed
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Henning P. Schmiedehausen wrote:
> Checking out the whole trunk is not the norm.
>
> Folks, this is not CVS. You are not bound to a rigid structure as with
> CVS. But you _want_ to be able to check out multiple projects side by
> side. Because some of the depend on each other (or on the commons-site
> module).
>
> A major nit that I have to pick is the growing number of project
> building with maven and the inability of _many_ maven plugins like the
> changelog, dev or file activity lists to _use_ subversion. This is
> actual information that we lose from the project sites if we go
> subversion.
>
Sure Henn, but IMHO, Jakarta Commons has always been a real "use case"
testing ground for Maven, It will not be long before those plugins are
migrated if Commons goes SVN, many Maven developers are also Commons
developers.
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Jakarta Commons Structure rehashed
Posted by Brett Porter <br...@apache.org>.
>Are these the versions released with 1.0.2? Also I feel uncomfortable
>with "works on one platform but not on another".
>
>
Yes. There is a windows specific bug in that release, so an updated
plugin will be made available for those publishing a site from a windows
machine.
This requires a manual install of a new plugin:
maven plugin:download -DgroupId=maven
-DartifactId=maven-changelog-plugin -Dversion=1.X.X
(this will fix all 3)
>Also, some plugins (quick grep; e.g. release) depend on SCM to do the
>right thing. A non-working release plugin is a no-go IMHO.
>
>
confusing aspect - the "release" was an experiment left around because
it provides some support code to other plugins.
The SCM plugin I mentioned has some release goals. These are all really
just convenience goals - certainly not something you need to use day-to-day.
The future goal is to redevelop these with complete requirements.
Deployment itself is unaffected.
>
>
>>I'm working on SCM, but commons does not at present use this anyway.
>>
>>
>
>How many commons components use maven for releasing?
>
>
AFAIK, just Jelly and Jexl. Hopefully by the time they come to a new
release, the new plugin will be ready for download. Its not a huge
amount of additional work
These are all issues, but not blocking IMO.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Jakarta Commons Structure rehashed
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Brett Porter <br...@apache.org> writes:
>Hi Henning,
Hi Brett,
>>A major nit that I have to pick is the growing number of project
>>building with maven and the inability of _many_ maven plugins like the
>>changelog, dev or file activity lists to _use_ subversion. This is
>>
>>
>many = 4. the 3 you listed, plus SCM.
>the 3 you listed work on linux, and there is a patch for windows that I
>am about to test and commit.
Are these the versions released with 1.0.2? Also I feel uncomfortable
with "works on one platform but not on another".
Also, some plugins (quick grep; e.g. release) depend on SCM to do the
right thing. A non-working release plugin is a no-go IMHO.
>I'm working on SCM, but commons does not at present use this anyway.
How many commons components use maven for releasing?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Jakarta Commons Structure rehashed
Posted by Brett Porter <br...@apache.org>.
Hi Henning,
I replied to this on jakarta general the other day.
>A major nit that I have to pick is the growing number of project
>building with maven and the inability of _many_ maven plugins like the
>changelog, dev or file activity lists to _use_ subversion. This is
>
>
many = 4. the 3 you listed, plus SCM.
the 3 you listed work on linux, and there is a patch for windows that I
am about to test and commit.
I'm working on SCM, but commons does not at present use this anyway.
gump and cruisecontrol, to the extent they use it, already work with
subversion.
If you find any other limitations, please let me know.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Jakarta Commons Structure rehashed
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Noel J. Bergman" <no...@devtech.com> writes:
>> I also prefer the flatter layout:
>> jakarta/commons/tags/
>> /branches
>> /trunk
>We don't version Commons as a single component, and I don't know that we
>want to force everyone to always take every single component. Someone
>wanting to build all of Commons is not the norm.
So check out jakarta/commons/trunk/digester and work there.
Checking out the whole trunk is not the norm.
Folks, this is not CVS. You are not bound to a rigid structure as with
CVS. But you _want_ to be able to check out multiple projects side by
side. Because some of the depend on each other (or on the commons-site
module).
A major nit that I have to pick is the growing number of project
building with maven and the inability of _many_ maven plugins like the
changelog, dev or file activity lists to _use_ subversion. This is
actual information that we lose from the project sites if we go
subversion.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Jakarta Commons Structure rehashed
Posted by Martin Cooper <mf...@gmail.com>.
On Sun, 19 Dec 2004 13:46:09 -0500, Mark R. Diggory
<md...@latte.harvard.edu> wrote:
>
>
> Martin Cooper wrote:
> >
> > That's fine and dandy if you're using an IDE such as Eclipse, but if
> > you don't use an IDE, it does make sense to just check out the whole
> > enchilada in one go. Or at least _I_ think it does. ;-)
> >
> > --
> > Martin Cooper
>
> You've got me thinking...
>
> The more I study SVN (and I'm pretty green here) the less the
> organization of the modules seems to effect what the user experiences.
> Right now I'm wondering if we've missed the basics here. Is it really
> not possible to organize the repository using (A) and still have the
> user be able to do
>
> svn checkout http://svn.apache.org/repos/asf/jakarta/commons
>
> why is this not possible? I seem to be able to do similar using eclipse.
That's certainly possible, but it would be highly inadvisable. The
problem is that using the URL you mentioned would get all trunks, tags
and branches for all components, which will probably run you out of
disk space. ;-)
What you really want to be able to do is:
svn checkout http://svn.apache.org/repos/asf/jakarta/commons/*/trunk
which would be the equivalent of what we do with CVS today when
checking out HEAD of jakarta-commons.
> In my opinion, its seems we are working on repository structuring of
> modules for managing versioning/taging, not what the user experiences
> when doing a checkout?
I think we're trying to find a compromise that satisfies both. As long
as someone can come up with a way to do the equivalent of the '*' URL
I mentioned above, I'd be happy with A + that script / tool / method.
--
Martin Cooper
> -Mark
>
> --
> Mark Diggory
> Software Developer
> Harvard MIT Data Center
> http://www.hmdc.harvard.edu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Jakarta Commons Structure rehashed
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Martin Cooper wrote:
>
> That's fine and dandy if you're using an IDE such as Eclipse, but if
> you don't use an IDE, it does make sense to just check out the whole
> enchilada in one go. Or at least _I_ think it does. ;-)
>
> --
> Martin Cooper
You've got me thinking...
The more I study SVN (and I'm pretty green here) the less the
organization of the modules seems to effect what the user experiences.
Right now I'm wondering if we've missed the basics here. Is it really
not possible to organize the repository using (A) and still have the
user be able to do
svn checkout http://svn.apache.org/repos/asf/jakarta/commons
why is this not possible? I seem to be able to do similar using eclipse.
In my opinion, its seems we are working on repository structuring of
modules for managing versioning/taging, not what the user experiences
when doing a checkout?
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Jakarta Commons Structure rehashed
Posted by Martin Cooper <mf...@gmail.com>.
On Sun, 19 Dec 2004 11:32:53 -0500, Mark R. Diggory
<md...@latte.harvard.edu> wrote:
> Sounds like we really all agree that the structure of the Commons is
> separate components. I think the big argument is that developers think
> that somehow it will be difficult to check everything out if the svn is
> organized in the same appropriate manner.
I'd prefer to call it a concern rather than an argument, but yes, I
think that's the gist of it. ;-)
> I'll argue that even in the cvs case, it usually doesn't make any
> logical sense to checkout the entire commons as one checkout, many of
> the components are organized to be mounted as separate projects in an
> IDE such as Eclipse. As such they need to be individually checked out
> and mounted as projects in Eclipse. With the Repository Browsing
> perspective in Eclipse, you can do this for multiple projects with the
> greatest of ease. I suspect its going to be just as easy to do this with
> SubEclipse.
That's fine and dandy if you're using an IDE such as Eclipse, but if
you don't use an IDE, it does make sense to just check out the whole
enchilada in one go. Or at least _I_ think it does. ;-)
--
Martin Cooper
> -Mark
>
> Noel J. Bergman wrote:
> >>I also prefer the flatter layout:
> >>jakarta/commons/tags/
> >> /branches
> >> /trunk
> >
> >
> > We don't version Commons as a single component, and I don't know that we
> > want to force everyone to always take every single component. Someone
> > wanting to build all of Commons is not the norm.
> >
> > --- Noel
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
> --
> Mark Diggory
> Software Developer
> Harvard MIT Data Center
> http://www.hmdc.harvard.edu
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Jakarta Commons Structure rehashed
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Sounds like we really all agree that the structure of the Commons is
separate components. I think the big argument is that developers think
that somehow it will be difficult to check everything out if the svn is
organized in the same appropriate manner.
I'll argue that even in the cvs case, it usually doesn't make any
logical sense to checkout the entire commons as one checkout, many of
the components are organized to be mounted as separate projects in an
IDE such as Eclipse. As such they need to be individually checked out
and mounted as projects in Eclipse. With the Repository Browsing
perspective in Eclipse, you can do this for multiple projects with the
greatest of ease. I suspect its going to be just as easy to do this with
SubEclipse.
-Mark
Noel J. Bergman wrote:
>>I also prefer the flatter layout:
>>jakarta/commons/tags/
>> /branches
>> /trunk
>
>
> We don't version Commons as a single component, and I don't know that we
> want to force everyone to always take every single component. Someone
> wanting to build all of Commons is not the norm.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
RE: Jakarta Commons Structure rehashed
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I also prefer the flatter layout:
> jakarta/commons/tags/
> /branches
> /trunk
We don't version Commons as a single component, and I don't know that we
want to force everyone to always take every single component. Someone
wanting to build all of Commons is not the norm.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org