You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Roy Russo <ro...@jboss.com> on 2005/07/02 17:02:44 UTC
build problems
I haven't checked out Jackrabbit in roughly a month. I did a clean
checkout today and could not build. I noticed the Jira tasks where
sources are being refactored in to core, commons, and api. Has the build
not been modified to reflect these changes?
Under root dir, running "maven jar", produces a 5kb
jackrabbit-1.0-dev.jar.
Regards,
Roy Russo
Jboss Portal Developer
Re: build problems
Posted by Jukka Zitting <jz...@yukatan.fi>.
Hi,
Some quick notes.
Roy T. Fielding wrote:
> Right now we have:
> [...]
> Unfortunately, I don't know what half of those directories
> are supposed to contain, nor how they would map to an ideal
> navigation structure for our website. In any case, the "contrib"
> directory has become a place to dump code, which is bad.
I was just thinking about updating the xdocs/layout.xml document for the
same reason. :-) You are right in that the directory and navigation
structure could use some gardening. Using the multiproject plugin sounds
like a good idea.
About the contrib dir. Should we promote some of the more mature contrib
projects as "official" Jackrabbit subprojects? I believe jcr-rmi,
jcr-server, and orm-persistence to be the most active contrib projects
at the moment and could well be "promoted". The rest of the contrib
projects could then be reviewed for whether to keep or drop them. For
example the goals of the jcr-ext package will soon be covered by the
jackrabbit-commons library. I'd like to see the contrib dir as a
"sandbox" for developing interesting ideas and contributions. A project
should be kept in contrib until a proper decision can be made on whether
to keep or drop it.
> Does anyone have a preference? Should we try to stick with the
> default maven (flat) layout for multiprojects, or subdivide the
> project into layers (e.g., main, gateways, persistence managers,
> connectors, misc), or use a flat layout with name prefixes
> (e.g., jcr-main, pm-orm, pm-vfs, gw-webdav, etc.), or some
> better idea that I haven't thought of yet?
I generally like flat layouts more, but don't really have a good opinion
for Jackrabbit.
> I'd like to end up with something that is reasonably intuitive
> when navigating the website. I'd also like to avoid doing the
> change in subversion more than once. However, I don't want the
> site to remain broken for too long, so if you have a strong
> opinion one way or the other then please let me know ASAP.
How about something like the following for web navigation?
General
The current documentation and other general info
Jackrabbit implementation
Documentation of the core, api, and (perhaps) commons packages.
Additional modules
Documentation of the "promoted" contrib subprojects
> I'll probably also switch to using Maven 1.1 beta, assuming it
> works, unless there are any objections.
No objections here.
BR,
Jukka Zitting
Re: build problems
Posted by Marcel Reutegger <ma...@gmx.net>.
Hi all,
Jukka Zitting wrote:
> Roy is right in that the directory layout could do with some cleaning
> up. A proposal:
>
> jackrabbit/
> ./api
> ./commons
> ./core
> ./applications
> ./xdocs
> ./subprojects
> ./jcr-rmi
> ./jcr-server
> ./orm-persistence
> ...
> ./contrib
> ./examples
> ./jcr-commands
> ./jcr-ext
> ./jcrtaglib
> ./phpcr
> ./tck-webapp
> ./textfilters
> ./vfs
> ...
I like the structure.
+1
> IDE and tool support
> --------------------
>
> It would be nicer for IDEs and various tools if the current main modules
> would _not_ extend the top level project.xml. For example at the moment
> you cannot just grab jackrabbit/commons and build it. Instead you need
> to get the whole Jackrabbit source tree to do this. As the top level
> project.xml contains mostly just descriptive information not directly
> used in building the sources, I'd propose removing this dependency. It
> would remove the contributor and mailing list information from the
> module projects, but I think we could manage with having that
> information only at the top level.
also makes it easier to include one of the subprojects into another one
with a svn:external.
+1
regards
marcel
Re: build problems
Posted by Brian Moseley <bc...@osafoundation.org>.
Jukka Zitting wrote:
> The -SNAPSHOT suffix causes Maven to try to download stuff from
> http://www.day.com/maven/jackrabbit/jars/, but at the moment this
> results in 403 Forbidden errors. I think Maven would be happier if
> someone at Day could arrange for 404 Not Found errors to be served. Or
> if possible, set up a nightly build script that would populate the
> directory with the latest Jackrabbit SNAPSHOTs. :-)
yes please :)
Re: build problems
Posted by Jukka Zitting <ju...@zitting.name>.
Hi,
I wrote:
> * Switch from -dev to -SNAPSHOT in project versioning
> * Break the extends dependencies to the top level project.xml
> * Use the Maven Multi-Project plugin for building api, commons and core
These are now done. Good commands for managing the top level build:
$ maven multiproject:install
$ maven multiproject:clean
$ maven multiproject:site
The -SNAPSHOT suffix causes Maven to try to download stuff from
http://www.day.com/maven/jackrabbit/jars/, but at the moment this
results in 403 Forbidden errors. I think Maven would be happier if
someone at Day could arrange for 404 Not Found errors to be served. Or
if possible, set up a nightly build script that would populate the
directory with the latest Jackrabbit SNAPSHOTs. :-)
> * Possibly upgrade to Maven 1.1
I didn't do this yet. We should probably wait until Maven 1.1 is out of
beta.
BR,
Jukka Zitting
Re: build problems
Posted by Jukka Zitting <ju...@zitting.name>.
Hi,
It seems that we need to discuss the scope issues a bit more before
reaching a consensus on what to do with component and release management.
However, to keep things from stalling, I'll now implement the following
actions for which there seems to be a consensus.
* Switch from -dev to -SNAPSHOT in project versioning
* Break the extends dependencies to the top level project.xml
* Use the Maven Multi-Project plugin for building api, commons and core
* Possibly upgrade to Maven 1.1
BR,
Jukka Zitting
Re: build problems
Posted by Edgar Poce <ed...@gmail.com>.
Hi
> What's the general opinion about this?
Summary:
--------
0 narrow the kind of tools included in jackrabbit
+1 /subprojects folder with a flat structure
+1 /subprojects/sandbox with a flat structure
+1 follow ASF guidelines for preparing releases before moving any
project from /subprojects/sandbox to /subprojects
---------
IMHO it's true that most of the projects in contrib are out of the scope
declared in the jackrabbit site[1], and it certainly leads to confusion
and disorder as Roy pointed. But for a time now there's an apparent
consensus on seeing Jackrabbit as an umbrella project of jcr related
"helpers or tools".
Maybe we should review the umbrella idea. What about narrowing the kind
of tools that fit in the project scope?. If the scope isn't narrowed I
guess someone should patch the docs.
Regarding the tree structure I think that every contrib project, whether
released or not, should be placed under a subproject folder. A top level
flat structure would dilute the jackrabbit main goal, namely the JCR RI.
Despite I admit that the increasing number of projects don't help, I
don't agree with Roy about the project names. I think that most of the
names are pretty clear and inform about the place in the architectural
layers. However, I think that it can be improved by following a pattern
like:
1 - jackrabbit-[ext name] pattern for jackrabbit specific extensions
2 - jcr-[tool name] pattern for applications built on top of JCR
3 - [lang name]-cr pattern for ports to another languages
I'd prefer a flat structure under /subprojects and under
/subprojects/sandbox, I think that clear names and documentation in the
site should give enough information to newcomers.
BR,
edgar
[1] quote "The purpose of this incubation period is ... to allow the
developers to focus on this interface/implementation rather than all of
the existing projects that might want to use it..."
Jukka Zitting wrote:
> Hi,
>
> Roy T. Fielding wrote:
>
>> I think it is a question of independence. AFAICT, the various gateways
>> under contrib are entirely dependent on the Jackrabbit project at the
>> moment and it would be very difficult for them to live independently.
>> JNDI, RMI, and webdav access seem to be very much in scope even when
>> they are coded to be independent of the JCR implementation, since
>> their purpose is to serve as deployment methods.
>
>
> At the moment yes, as there are yet only a few real JCR implementations
> out there, but what about later. The gateway components as well as the
> underlying "commons" code is definitely useful for other projects as
> well. Treating them as ordinary parts of the Jackrabbit implementation
> will introduce troublesome partially-outside-the-project-scope
> components within Jackrabbit. Of course this is also the current
> situation, but at least we now have the contrib subdirectory keeping the
> line... :-)
>
> Another point to consider in drawing the scope line is the architectural
> layering of the components. Many of these components in question live at
> the opposite side of the JCR API layer, and thus considerably widen the
> architectural scope of Jackrabbit.
>
> +-------------------+
> | RMI, Webdav, etc. |
> +-------------------+
> | JCR |
> +-------------------+
> | Jackrabbit |
> +-------------------+
>
>> Both RMI and webdav are useful deployment mechanisms and, as such,
>> should be managed by the project and released as such for now.
>> Do you think that they are sustainable outside Jackrabbit? I mean,
>> do you think that Apache could eventually organize at least three
>> independent collaborators to run such a project outside of
>> Jackrabbit? I have a hard time believing that will ever be the
>> case, since interface layers tend to be one or two-person projects.
>
>
> Not as separate projects perhaps, but I certainly see a need for a
> common implementation-independent base of JCR components and tools. If
> such a base should not be maintained within the Jackrabbit project, then
> perhaps we should revisit the idea of a Commons-JCR project that was
> briefly discussed during the last winter.
>
> I think that a Commons project that would include for example RMI ja
> Webdav layers and the recently added commons-chain commands in addition
> to the general-purpose support code (ISO8601, Value handling, etc.) from
> jackrabbit-commons could easily support a diverse-enough community for
> the project to stand on it's own.
>
> What's the general opinion about this?
>
>>> I'm a bit worried about essentially renaming everything. Even if the
>>> original component names perhaps aren't perfect, there's already
>>> quite a lot of community buy-in, existing code, and mailing list
>>> references to names like jcr-rmi and orm-persistence.
>>
>>
>> I don't buy this argument. There is no dependence on the existing
>> names, but there will be six months from now. We haven't made a
>> release yet and we are still in incubator, so I can't accept an
>> argument that there is a lot of buy-in from the community, and
>> the fact that it will become harder very soon should be motivation
>> to get the names right now. We need to imagine how people will
>> view the release and choose names according to the goal of helping
>> them understand. I want those names to be as clear as possible
>> before we spend a great deal of effort over the next few months
>> on documentation.
>
>
> OK, you're probably right. Little pain now to avoid bigger pain later. I
> can live with this. :-)
>
> BR,
>
> Jukka Zitting
>
>
>
Re: build problems
Posted by Jukka Zitting <ju...@zitting.name>.
Hi,
Roy T. Fielding wrote:
> I think it is a question of independence. AFAICT, the various gateways
> under contrib are entirely dependent on the Jackrabbit project at the
> moment and it would be very difficult for them to live independently.
> JNDI, RMI, and webdav access seem to be very much in scope even when
> they are coded to be independent of the JCR implementation, since
> their purpose is to serve as deployment methods.
At the moment yes, as there are yet only a few real JCR implementations
out there, but what about later. The gateway components as well as the
underlying "commons" code is definitely useful for other projects as
well. Treating them as ordinary parts of the Jackrabbit implementation
will introduce troublesome partially-outside-the-project-scope
components within Jackrabbit. Of course this is also the current
situation, but at least we now have the contrib subdirectory keeping the
line... :-)
Another point to consider in drawing the scope line is the architectural
layering of the components. Many of these components in question live at
the opposite side of the JCR API layer, and thus considerably widen the
architectural scope of Jackrabbit.
+-------------------+
| RMI, Webdav, etc. |
+-------------------+
| JCR |
+-------------------+
| Jackrabbit |
+-------------------+
> Both RMI and webdav are useful deployment mechanisms and, as such,
> should be managed by the project and released as such for now.
> Do you think that they are sustainable outside Jackrabbit? I mean,
> do you think that Apache could eventually organize at least three
> independent collaborators to run such a project outside of
> Jackrabbit? I have a hard time believing that will ever be the
> case, since interface layers tend to be one or two-person projects.
Not as separate projects perhaps, but I certainly see a need for a
common implementation-independent base of JCR components and tools. If
such a base should not be maintained within the Jackrabbit project, then
perhaps we should revisit the idea of a Commons-JCR project that was
briefly discussed during the last winter.
I think that a Commons project that would include for example RMI ja
Webdav layers and the recently added commons-chain commands in addition
to the general-purpose support code (ISO8601, Value handling, etc.) from
jackrabbit-commons could easily support a diverse-enough community for
the project to stand on it's own.
What's the general opinion about this?
>> I'm a bit worried about essentially renaming everything. Even if the
>> original component names perhaps aren't perfect, there's already quite
>> a lot of community buy-in, existing code, and mailing list references
>> to names like jcr-rmi and orm-persistence.
>
> I don't buy this argument. There is no dependence on the existing
> names, but there will be six months from now. We haven't made a
> release yet and we are still in incubator, so I can't accept an
> argument that there is a lot of buy-in from the community, and
> the fact that it will become harder very soon should be motivation
> to get the names right now. We need to imagine how people will
> view the release and choose names according to the goal of helping
> them understand. I want those names to be as clear as possible
> before we spend a great deal of effort over the next few months
> on documentation.
OK, you're probably right. Little pain now to avoid bigger pain later. I
can live with this. :-)
BR,
Jukka Zitting
Re: build problems
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jul 11, 2005, at 5:31 AM, Jukka Zitting wrote:
> Roy T. Fielding wrote:
>> I am going to disagree a little bit. We need to figure out what
>> will be included in an eventual 1.0 release and build all of it.
>
> I'd prefer to keep the project scope limited to "Implementation of the
> Content Repository for Java" as written in the project descriptor.
> Thus none of the current contrib packages would be included in the
> release.
I could certainly go along with that, but then why do they exist in
our subversion? Personally, I don't think we should be managing
code that we don't intend to release sometime. If their purpose is
to be an example for documentation, then they should be organized
as examples rather than as code dumps.
I think the bulk of that code is intended as either deployment
methods or examples for reducing the chicken-and-egg problem:
encouraging applications to build stuff on top of JCR while at
the same time exploring various use-cases for JCR. However,
I have no clue where the phpcr stuff belongs, so we do need a
sandbox of some kind for now until things like that can move
to their own incubator project.
>> Also, I don't believe Apache should have visible subprojects.
>> Projects have a habit of forgetting that they are responsible
>> for the entire contents of version control and subprojects
>> get twisted into fiefdoms.
>
> I see the point. However I don't think it would be wise to widen the
> stated project scope into "Various stuff related to JCR". Some
> thoughts about this:
>
> Currently I think the Jackrabbit *community scope* as significantly
> wider than the Jackrabbit *project scope*. As discussed six months
> ago, the Jackrabbit community is forming up to be a central place for
> things related to JCR. If JCR lives up to its potential, I can
> envision a need for a top level Apache JCR project like the existing
> DB, logging, XML, and WS projects. In that sense I think the concept
> of subprojects fits our needs very well.
Jackrabbit needs to have one scope and that is managing the code
that it intends to release. This project is already heading to TLP
status after incubation, with similar scope to the APR project.
Umbrella projects like Jakarta, DB, XML, and WS are things of
the past -- they are gradually separating into smaller, sustainable
projects, leaving the umbrellas only responsible for commons code and
shared interfaces/documentation. I am not a big fan of communities
that are larger than projects, since they don't do a very good job
of quality control.
> But it is clear that such progress is just starting and that at the
> moment there certainly isn't enough interest for example to split
> JCR-RMI into a self-contained project with its own community. I think
> it would be quite interesting and helpful to learn from similar cases
> in the Apache history.
I think it is a question of independence. AFAICT, the various gateways
under contrib are entirely dependent on the Jackrabbit project at the
moment and it would be very difficult for them to live independently.
JNDI, RMI, and webdav access seem to be very much in scope even when
they are coded to be independent of the JCR implementation, since
their purpose is to serve as deployment methods. Likewise, the
directory structure should lead the code base towards plug-in
persistence managers, since that is an obvious extensibility point.
Most of the other things in contrib are simply thrown there with
no rhyme or reason, interfering with comprehension of the project.
> Of course it would be possible to solve this issue by declaring
> components like JCR-RMI parts of the Jackrabbit implementation that
> just happen to have only general JCR dependencies. This might be a
> reasonable short term solution, but in the long run I'd prefer to
> manage such cleanly scoped components as independent subprojects with
> separate release schedules etc.
Both RMI and webdav are useful deployment mechanisms and, as such,
should be managed by the project and released as such for now.
Do you think that they are sustainable outside Jackrabbit? I mean,
do you think that Apache could eventually organize at least three
independent collaborators to run such a project outside of
Jackrabbit? I have a hard time believing that will ever be the
case, since interface layers tend to be one or two-person projects.
>> So, for those reasons, I would prefer
>
> I'm a bit worried about essentially renaming everything. Even if the
> original component names perhaps aren't perfect, there's already quite
> a lot of community buy-in, existing code, and mailing list references
> to names like jcr-rmi and orm-persistence.
I don't buy this argument. There is no dependence on the existing
names, but there will be six months from now. We haven't made a
release yet and we are still in incubator, so I can't accept an
argument that there is a lot of buy-in from the community, and
the fact that it will become harder very soon should be motivation
to get the names right now. We need to imagine how people will
view the release and choose names according to the goal of helping
them understand. I want those names to be as clear as possible
before we spend a great deal of effort over the next few months
on documentation.
....Roy
Re: build problems
Posted by Jukka Zitting <jz...@yukatan.fi>.
Hi,
Roy T. Fielding wrote:
> I am going to disagree a little bit. We need to figure out what
> will be included in an eventual 1.0 release and build all of it.
I'd prefer to keep the project scope limited to "Implementation of the
Content Repository for Java" as written in the project descriptor. Thus
none of the current contrib packages would be included in the release.
> Also, I don't believe Apache should have visible subprojects.
> Projects have a habit of forgetting that they are responsible
> for the entire contents of version control and subprojects
> get twisted into fiefdoms.
I see the point. However I don't think it would be wise to widen the
stated project scope into "Various stuff related to JCR". Some thoughts
about this:
Currently I think the Jackrabbit *community scope* as significantly
wider than the Jackrabbit *project scope*. As discussed six months ago,
the Jackrabbit community is forming up to be a central place for things
related to JCR. If JCR lives up to its potential, I can envision a need
for a top level Apache JCR project like the existing DB, logging, XML,
and WS projects. In that sense I think the concept of subprojects fits
our needs very well.
But it is clear that such progress is just starting and that at the
moment there certainly isn't enough interest for example to split
JCR-RMI into a self-contained project with its own community. I think it
would be quite interesting and helpful to learn from similar cases in
the Apache history.
Of course it would be possible to solve this issue by declaring
components like JCR-RMI parts of the Jackrabbit implementation that
just happen to have only general JCR dependencies. This might be a
reasonable short term solution, but in the long run I'd prefer to manage
such cleanly scoped components as independent subprojects with separate
release schedules etc.
> So, for those reasons, I would prefer
I'm a bit worried about essentially renaming everything. Even if the
original component names perhaps aren't perfect, there's already quite a
lot of community buy-in, existing code, and mailing list references to
names like jcr-rmi and orm-persistence.
How about adopting the proposed directory structure you proposed but
keeping the existing component names?
BR,
Jukka Zitting
Re: build problems
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jul 11, 2005, at 2:48 AM, Jukka Zitting wrote:
> Thanks for the +1s. Roy, what do you think, can I go on implementing
> the proposal or do you want to tweak the Maven setup yourself? Are you
> using the standard Maven site goal to generate the site, or are there
> some special steps I should be aware of?
I was using "maven site:deploy". I was going to replace that with
"maven multisite:site-deploy" as per the docs, though it did not
seem to work with projects at depth > 1. It may be better to
override "maven site" in the top-level build, but that is as far
as I got before getting sidetracked.
> Stefan Guggisberg wrote:
>> in general +1; however, if the subprojects were to be included in the
>> top level multiproject it should still be possible to build 'just'
>> jackrabbit
>> without the subprojects. i am a little worried that work on core
>> could be hampered otherwise. there's still the possibility of
>> necessary
>> major changes in the core that could break some subprojects.
>
> That's reasonable. OK, if the subprojects are included in the site
> build as a postGoal? Alternatively we could separately commit the
> generated subproject sites under site/subprojects.
I am going to disagree a little bit. We need to figure out what
will be included in an eventual 1.0 release and build all of it.
The core cannot be allowed to break the rest of the release as we
do today, so we need to be in the habit of making such changes
across the entire code base in a single commit. With that perspective
in mind, I'd like to move "contrib" to "sandbox" and organize
everything else according to their function within Jackrabbit.
I should be able to look at the release directories and have a clue
what each part does for Jackrabbit. "core", "api", "commons",
"jcr-server", "jcr-ext", and "jcr-rmi" are all terrible names for
trying to explain to a developer where to look for what functions.
Also, I don't believe Apache should have visible subprojects.
Projects have a habit of forgetting that they are responsible
for the entire contents of version control and subprojects
get twisted into fiefdoms.
So, for those reasons, I would prefer
jackrabbit/
./shared (jackrabbit code used by below modules and
jcr-ext)
./jcr (everything needed for JCR implementation)
./examples (buildable usage examples)
./gateways
./orm2jcr
./rmi2jcr
./taglib2jcr
./webdav2jcr
...
./persistence
./jcr2fs
./jcr2jdbc
...
./sandbox (not included in release jars)
./textfilters
./phpcr
...
./test
./jmeter-commands
./tck-webapp
./xdocs
Would that make sense to someone working with Jackrabbit for
the first time? I probably have less experience with the code
than anyone else at Day, but I think one of the reasons we have
so little documentation is because it is very difficult to
figure our where to start.
....Roy
Re: build problems
Posted by Jukka Zitting <jz...@yukatan.fi>.
Hi,
Thanks for the +1s. Roy, what do you think, can I go on implementing the
proposal or do you want to tweak the Maven setup yourself? Are you using
the standard Maven site goal to generate the site, or are there some
special steps I should be aware of?
Stefan Guggisberg wrote:
> in general +1; however, if the subprojects were to be included in the
> top level multiproject it should still be possible to build 'just' jackrabbit
> without the subprojects. i am a little worried that work on core could
> be hampered otherwise. there's still the possibility of necessary
> major changes in the core that could break some subprojects.
That's reasonable. OK, if the subprojects are included in the site build
as a postGoal? Alternatively we could separately commit the generated
subproject sites under site/subprojects.
BR,
Jukka Zitting
Re: build problems
Posted by Stefan Guggisberg <st...@gmail.com>.
hi jukka,
On 7/10/05, Jukka Zitting <jz...@yukatan.fi> wrote:
> Hi,
>
> Some more ideas after thinking about the build issues a bit more.
>
> Directory layout
> ----------------
>
> Roy is right in that the directory layout could do with some cleaning
> up. A proposal:
>
> jackrabbit/
> ./api
> ./commons
> ./core
> ./applications
> ./xdocs
> ./subprojects
> ./jcr-rmi
> ./jcr-server
> ./orm-persistence
> ...
> ./contrib
> ./examples
> ./jcr-commands
> ./jcr-ext
> ./jcrtaglib
> ./phpcr
> ./tck-webapp
> ./textfilters
> ./vfs
> ...
>
> Commentary:
>
> * We'd keep the main Jackrabbit components (api, commons, and core) at
> the top level as they are now. They can be built and managed using a
> Maven multiproject setup at the top level Jackrabbit directory.
+1
>
> * The mature subprojects (like jcr-server) would be placed in
> ./subprojects and managed as independent entities. It might be useful to
> include also them in the top level multiproject setup. At least they
> should be included in the site build. The same level of commit
> discipline (little or no failing builds) would be required as for the
> main components.
in general +1; however, if the subprojects were to be included in the
top level multiproject it should still be possible to build 'just' jackrabbit
without the subprojects. i am a little worried that work on core could
be hampered otherwise. there's still the possibility of necessary
major changes in the core that could break some subprojects.
>
> * The contrib projects would remain in ./contrib. They'd not be included
> in any of the top level builds, but (if made possible by the main site
> build script) contrib authors could commit their site builds to
> site/contrib to publish information about the contrib projects on the
> Jackrabbit web site.
+1
>
> * The ./application and ./xdocs directories remain as they are. I'm not
> totally happy with the current use of the ./application/test repository
> directory (it would be nicer to have it inside ./target), but that's
> another discussion.
+1
>
> Top-level build
> ---------------
>
> As proposed by Roy, we should use the Maven Multi-Project plugin to
> manage builds at the top level. The maven.multiproject.includes property
> should be either the default (include only the main modules) or
> "*/project.xml,subprojects/*/project.xml" (include also the mature
> subprojects).
+1
>
> Additionally, to avoid dependency problems like the recent "maven clean"
> issue, we should change the "-dev" suffix to the Maven-standard
> "-SNAPSHOT" and start publishing periodic binary snapshots either on the
> Day repository or at Ibiblio. This would be nice for other purposes as well.
+1
>
> Web site navigation
> -------------------
>
> Following the above directory layout proposal, we could divide the web
> site like this:
>
> Apache Jackrabbit
> [the current documentation]
> Jackrabbit components
> Jackrabbit API
> Jackrabbit Commons
> Jackrabbit Core
> Jackrabbit subprojects
> JCR-RMI
> JCR Server
> ORM Persistence
> ...
> Jackrabbit contributions
> ...
>
> The new sections would contain pointers to the individual subsites
> generated by multiproject. General documentation would remain at the top
> level, and the technical details (generated javadocs, developer
> instructions, TODOs, etc.) would be included in the subsites.
+1
>
> IDE and tool support
> --------------------
>
> It would be nicer for IDEs and various tools if the current main modules
> would _not_ extend the top level project.xml. For example at the moment
> you cannot just grab jackrabbit/commons and build it. Instead you need
> to get the whole Jackrabbit source tree to do this. As the top level
> project.xml contains mostly just descriptive information not directly
> used in building the sources, I'd propose removing this dependency. It
> would remove the contributor and mailing list information from the
> module projects, but I think we could manage with having that
> information only at the top level.
+1
btw: great job, thanks for taking the lead on this task!
cheers
stefan
>
> BR,
>
> Jukka Zitting
>
Re: build problems
Posted by Fabrizio Giustina <fg...@gmail.com>.
On 7/11/05, Marcel Reutegger <ma...@gmx.net> wrote:
> Could you please provide a patch for the project.xml files with your
> suggested changes?
Done, see http://issues.apache.org/jira/browse/JCR-167
> > [note, there are a few spurious "applications/test"
> > resource dirs configured in api and commons which should be removed]
I saw this was already fixed in svn
thanks
fabrizio
Re: build problems
Posted by Marcel Reutegger <ma...@gmx.net>.
Hi Fabrizio,
Fabrizio Giustina wrote:
> Regarding this topic, what I'd like to see are a few maven settings
> that let you completely configure all the jackrabbit projects in
> eclipse, namely:
>
> - add the maven.eclipse.resources.addtoclasspath=true property to
> project.properties (make the eclipse plugin create source dirs also
> for resources). [note, there are a few spurious "applications/test"
> resource dirs configured in api and commons which should be removed]
>
> - add the <eclipse.dependency>true</eclipse.dependency> property to
> all the jackrabbit internal dependencies in all the POMs (all the
> dependencies with "jackrabbit" groupId) so internal dependencies
> becomes project dependencies in eclipse.
Could you please provide a patch for the project.xml files with your
suggested changes?
thanks.
regards
marcel
Re: build problems
Posted by Fabrizio Giustina <fg...@gmail.com>.
On 7/10/05, Jukka Zitting <jz...@yukatan.fi> wrote:
> Additionally, to avoid dependency problems like the recent "maven clean"
> issue, we should change the "-dev" suffix to the Maven-standard
> "-SNAPSHOT" and start publishing periodic binary snapshots either on the
> Day repository or at Ibiblio. This would be nice for other purposes as well.
That would be great. It's a pity that, while jackrabbit uses maven for
its build, you can't use maven to manage the dependencies of a
jackrabbit-based application... also if jackrabbit has never been
released there are already a lot of jackrabbit "users" out there:
please be kind and publish snapshot binary builds ;)
> Directory layout
> ----------------
>
> Roy is right in that the directory layout could do with some cleaning
> up. A proposal:
After the restructuring of the core I think the same principle should
be applied to the orm persistence project...
I was willing to contribute an hibernate3 implementation but it's
impossible to integrate it in the current orm module due to its layout
(a single project for core, ojb and hibernate2). What about splitting
it into orm-core, orm-ojb and orm-hibernate2 as well? It's pretty easy
to do since h2 and ojb implementations already are in specific
packages... anyway I offer my help if it's needed.
Another small issue is that tests are always configured to be run from
a specific parent dir (projects in contrib look for the parent core
jackrabbit directory). That's usually fine, but what about adding a
variable in project.xml in order to configure the location of the test
directory? That could be more ide friendly, if you don't want to nest
project and move projects in the contrib directory to the top level.
> IDE and tool support
> --------------------
>
> It would be nicer for IDEs and various tools if the current main modules
> would _not_ extend the top level project.xml.
That could be an improvement, but I don't think it's a big issue since
you can simply check out the project you need + the root project.xml.
Regarding this topic, what I'd like to see are a few maven settings
that let you completely configure all the jackrabbit projects in
eclipse, namely:
- add the maven.eclipse.resources.addtoclasspath=true property to
project.properties (make the eclipse plugin create source dirs also
for resources). [note, there are a few spurious "applications/test"
resource dirs configured in api and commons which should be removed]
- add the <eclipse.dependency>true</eclipse.dependency> property to
all the jackrabbit internal dependencies in all the POMs (all the
dependencies with "jackrabbit" groupId) so internal dependencies
becomes project dependencies in eclipse.
> Jukka Zitting
fabrizio
Re: build problems
Posted by Jukka Zitting <jz...@yukatan.fi>.
Hi,
Some more ideas after thinking about the build issues a bit more.
Directory layout
----------------
Roy is right in that the directory layout could do with some cleaning
up. A proposal:
jackrabbit/
./api
./commons
./core
./applications
./xdocs
./subprojects
./jcr-rmi
./jcr-server
./orm-persistence
...
./contrib
./examples
./jcr-commands
./jcr-ext
./jcrtaglib
./phpcr
./tck-webapp
./textfilters
./vfs
...
Commentary:
* We'd keep the main Jackrabbit components (api, commons, and core) at
the top level as they are now. They can be built and managed using a
Maven multiproject setup at the top level Jackrabbit directory.
* The mature subprojects (like jcr-server) would be placed in
./subprojects and managed as independent entities. It might be useful to
include also them in the top level multiproject setup. At least they
should be included in the site build. The same level of commit
discipline (little or no failing builds) would be required as for the
main components.
* The contrib projects would remain in ./contrib. They'd not be included
in any of the top level builds, but (if made possible by the main site
build script) contrib authors could commit their site builds to
site/contrib to publish information about the contrib projects on the
Jackrabbit web site.
* The ./application and ./xdocs directories remain as they are. I'm not
totally happy with the current use of the ./application/test repository
directory (it would be nicer to have it inside ./target), but that's
another discussion.
Top-level build
---------------
As proposed by Roy, we should use the Maven Multi-Project plugin to
manage builds at the top level. The maven.multiproject.includes property
should be either the default (include only the main modules) or
"*/project.xml,subprojects/*/project.xml" (include also the mature
subprojects).
Additionally, to avoid dependency problems like the recent "maven clean"
issue, we should change the "-dev" suffix to the Maven-standard
"-SNAPSHOT" and start publishing periodic binary snapshots either on the
Day repository or at Ibiblio. This would be nice for other purposes as well.
Web site navigation
-------------------
Following the above directory layout proposal, we could divide the web
site like this:
Apache Jackrabbit
[the current documentation]
Jackrabbit components
Jackrabbit API
Jackrabbit Commons
Jackrabbit Core
Jackrabbit subprojects
JCR-RMI
JCR Server
ORM Persistence
...
Jackrabbit contributions
...
The new sections would contain pointers to the individual subsites
generated by multiproject. General documentation would remain at the top
level, and the technical details (generated javadocs, developer
instructions, TODOs, etc.) would be included in the subsites.
IDE and tool support
--------------------
It would be nicer for IDEs and various tools if the current main modules
would _not_ extend the top level project.xml. For example at the moment
you cannot just grab jackrabbit/commons and build it. Instead you need
to get the whole Jackrabbit source tree to do this. As the top level
project.xml contains mostly just descriptive information not directly
used in building the sources, I'd propose removing this dependency. It
would remove the contributor and mailing list information from the
module projects, but I think we could manage with having that
information only at the top level.
BR,
Jukka Zitting
Re: build problems
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
I've been trying to figure out how the site build should work,
given that restructuring the source completely broke my site
generation script. The maven documentation is too general to
provide any useful advice.
Basically, the current project file is hand-jiggered to work
for buildall but nothing else. A more sensible plan would be
to use maven's multiproject feature across the entire tree.
Right now we have:
jackrabbit/
./api
./applications
./commons
./contrib
./examples
./jcr-commands
./jcr-ext
./jcr-rmi
./jcr-server
./jcrtaglib
./orm-persistence
./phpcr
./tck-webapp
./textfilters
./vfs
./core
./src
./grammar
./target
./xdocs
Unfortunately, I don't know what half of those directories
are supposed to contain, nor how they would map to an ideal
navigation structure for our website. In any case, the "contrib"
directory has become a place to dump code, which is bad.
Does anyone have a preference? Should we try to stick with the
default maven (flat) layout for multiprojects, or subdivide the
project into layers (e.g., main, gateways, persistence managers,
connectors, misc), or use a flat layout with name prefixes
(e.g., jcr-main, pm-orm, pm-vfs, gw-webdav, etc.), or some
better idea that I haven't thought of yet?
I'd like to end up with something that is reasonably intuitive
when navigating the website. I'd also like to avoid doing the
change in subversion more than once. However, I don't want the
site to remain broken for too long, so if you have a strong
opinion one way or the other then please let me know ASAP.
I'll probably also switch to using Maven 1.1 beta, assuming it
works, unless there are any objections.
....Roy
Re: build problems
Posted by Jukka Zitting <jz...@yukatan.fi>.
Hi,
Tobias Strasser work:
> the build should now work again. it produces a:
> - jackrabbit/core/target/jackrabbit-core-1.0-dev.jar
> - jackrabbit/commons/target/jackrabbit-commons-1.0-dev.jar
> - jackrabbit/api/target/jackrabbit-api-1.0-dev.jar
You need to run "maven" or "maven buildall" in the root directory to
build Jackrabbit. Running "maven jar" will currently produce a dummy
jackrabbit-1.0-dev.jar. We should probably add a postGoal or whatever to
catch the "maven jar" use case.
> actually i don't know, how we should handle building docs, dists
> etc...how do other projects do this? should we copy all stuff back to
> the toplevel project after building?
Sometime ago I was thinking about extending the site build to include
also the contrib packages so that for example the contrib/jcr-rmi Maven
site would automatically be deployed to
http://incubator.apache.org/jackrabbit/contrib/jcr-rmi/. This would be
relatively easy to do also for the three new main subdirectories.
The drawback of this solution is that we'd have three separate but
related addresses for example for the Jackrabbit javadocs.
An alternative would be to specify the source paths of all the main
subdirectories ({api,common,core}/src/java) in the top-level project.xml
and use that to generate the main javadocs and other project reports.
This approach would probably be somewhat confusing in the long run.
BR,
Jukka Zitting
Re: build problems
Posted by Tobias Strasser <to...@gmail.com>.
the build should now work again. it produces a:
- jackrabbit/core/target/jackrabbit-core-1.0-dev.jar
- jackrabbit/commons/target/jackrabbit-commons-1.0-dev.jar
- jackrabbit/api/target/jackrabbit-api-1.0-dev.jar
there should be no jackrabbit-1.0-dev.jar in the toplevel project generated.
for your apllications, you need all three of those jars.
actually i don't know, how we should handle building docs, dists
etc...how do other projects do this? should we copy all stuff back to
the toplevel project after building?
inputs are welcome.
cheers, tobi
On 7/2/05, Roy Russo <ro...@jboss.com> wrote:
> I haven't checked out Jackrabbit in roughly a month. I did a clean
> checkout today and could not build. I noticed the Jira tasks where
> sources are being refactored in to core, commons, and api. Has the build
> not been modified to reflect these changes?
>
> Under root dir, running "maven jar", produces a 5kb
> jackrabbit-1.0-dev.jar.
>
> Regards,
> Roy Russo
> Jboss Portal Developer
>
>
>
--
------------------------------------------< tobias.strasser@day.com >---
Tobias Strasser, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: build problems
Posted by Jukka Zitting <jz...@yukatan.fi>.
Hi,
Roy Russo wrote:
> I haven't checked out Jackrabbit in roughly a month. I did a clean
> checkout today and could not build. I noticed the Jira tasks where
> sources are being refactored in to core, commons, and api. Has the build
> not been modified to reflect these changes?
Sorry for the problems. There was just a major restructuring of the
code, and the build environment and related instructions have not yet
fully caught up with the changes. It'll probably take a few days before
things have settled down.
Meanwhile, you may want to checkout a version dated before 2005-07-01
(revision 208754) unless you wish to participate in working out the
details of this restructuring.
BR,
Jukka Zitting