On 08.03.2007, at 07:48, Reinhard Poetz wrote:
Reinhard Poetz wrote:
Yesterday I did a svn up on commons-jci and get errors of type
ClassDefNotFoundError. After reloading it again, the error
disappears. After testing commons-jci built on Sunday afternoon,
everything works as expected.
Torsten Curdt wrote:
On 08.03.2007, at 07:48, Reinhard Poetz wrote:
Reinhard Poetz wrote:
Yesterday I did a svn up on commons-jci and get errors of type
ClassDefNotFoundError. After reloading it again, the error
disappears. After testing commons-jci built on Sunday afternoon,
everything
Yesterday I did a svn up on commons-jci and get errors of type
ClassDefNotFoundError. After reloading it again, the error disappears. After
testing commons-jci built on Sunday afternoon, everything works as expected.
Maybe I'm doing something wrong in
Reinhard Poetz wrote:
Yesterday I did a svn up on commons-jci and get errors of type
ClassDefNotFoundError. After reloading it again, the error disappears.
After testing commons-jci built on Sunday afternoon, everything works as
expected.
Once again ;-)
Yesterday I did a svn up on
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
Giacomo Pati wrote:
How is the rcl-plugin related/overlapping with the deployer-plugin?
I've put some work making the deployer-plugin usable for block
development and now I'm asking
whether that work
On 05.03.2007, at 07:31, Reinhard Poetz wrote:
Torsten Curdt wrote:
On 04.03.2007, at 18:40, Reinhard Poetz wrote:
Torsten Curdt wrote:
On 04.03.2007, at 17:59, Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
Reinhard Poetz napisał(a):
Just a warning, AFAICS it's not a drop-in
Torsten Curdt wrote:
BTW, where did you get the commons-jci dependency from? Did you build
it from SVN?
Huh? Am I supposed to do this?
I just fired mvn install and got this:
Downloading:
Giacomo Pati wrote:
How is the rcl-plugin related/overlapping with the deployer-plugin?
I've put some work making the deployer-plugin usable for block development and
now I'm asking
whether that work is becoming obsolete and I should migrate ev. missing
features into the rcl-plugin
I've
Grzegorz Kossakowski wrote:
Torsten Curdt napisaÅ(a):
Definitely! ...please use latest trunk!
No problem. Howver, root pom of commons-jci is broken, you have jci as
artifactId but it should be commons-jci.
I had to disable tests because many of them fail. Is it known issue?
Now going to
Reinhard Poetz napisał(a):
Just a warning, AFAICS it's not a drop-in replacement because of
some API changes.
Thanks for fixing this. Unfortunately, nothing changed after replacing
jci with the current trunk. Still class reloading does not work while
running outside the Eclipse and still
Grzegorz Kossakowski wrote:
Reinhard Poetz napisał(a):
Just a warning, AFAICS it's not a drop-in replacement because of
some API changes.
Thanks for fixing this. Unfortunately, nothing changed after replacing
jci with the current trunk. Still class reloading does not work while
running
On 04.03.2007, at 17:59, Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
Reinhard Poetz napisał(a):
Just a warning, AFAICS it's not a drop-in replacement because
of some API changes.
Thanks for fixing this. Unfortunately, nothing changed after
replacing jci with the current trunk.
On 03.03.2007, at 19:53, Grzegorz Kossakowski wrote:
Torsten Curdt napisał(a):
Definitely! ...please use latest trunk!
No problem. Howver, root pom of commons-jci is broken, you have
jci as artifactId but it should be commons-jci.
Well, broken ;) ...as the groupId is now using the
Torsten Curdt wrote:
On 04.03.2007, at 17:59, Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
Reinhard Poetz napisaÅ(a):
Just a warning, AFAICS it's not a drop-in replacement because of
some API changes.
Thanks for fixing this. Unfortunately, nothing changed after
replacing jci with
Torsten Curdt napisał(a):
On 03.03.2007, at 19:53, Grzegorz Kossakowski wrote:
Torsten Curdt napisał(a):
Definitely! ...please use latest trunk!
No problem. Howver, root pom of commons-jci is broken, you have jci
as artifactId but it should be commons-jci.
Well, broken ;) ...as the
Torsten Curdt napisał(a):
What filesystem?
Forgot about file system in previous mail. I have NTFS partitions.
--
Grzegorz Kossakowski
Well, broken ;) ...as the groupId is now using the maven2 scheme
the commons is already included in there.
But I will bring that up on commons dev to see how we will handle
this.
I agree but now eveywhere else commons- prefix is used in
artifact ids so you have to change it everywhere or
On 04.03.2007, at 18:40, Reinhard Poetz wrote:
Torsten Curdt wrote:
On 04.03.2007, at 17:59, Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
Reinhard Poetz napisał(a):
Just a warning, AFAICS it's not a drop-in replacement because
of some API changes.
Thanks for fixing this.
Torsten Curdt wrote:
On 04.03.2007, at 18:40, Reinhard Poetz wrote:
Torsten Curdt wrote:
On 04.03.2007, at 17:59, Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
Reinhard Poetz napisał(a):
Just a warning, AFAICS it's not a drop-in replacement because of
some API changes.
Thanks for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
Giacomo Pati wrote:
How is the rcl-plugin related/overlapping with the deployer-plugin?
I've put some work making the deployer-plugin usable for block
development and now I'm asking
whether that work is becoming
Grzegorz Kossakowski wrote:
Reinhard Poetz napisał(a):
Using the reloading-classloader-plugin you can run a block as the
plugin creates a default Cocoon webapp and deploys the block into it.
And, as the blocks name conveys, it takes care that you can work on
Cocoon resources and Java sources
Reinhard Poetz napisał(a):
Grzegorz Kossakowski wrote:
5. Finally, fifth step. Should clean and package goals be omitted
while calling jetty:run goal?
don't call clean. It would remove the RCL web application again.
Calling package would be useless.
mvn jetty:run is enough.
I tried to
Grzegorz Kossakowski wrote:
Reinhard Poetz napisał(a):
Grzegorz Kossakowski wrote:
5. Finally, fifth step. Should clean and package goals be omitted
while calling jetty:run goal?
don't call clean. It would remove the RCL web application again.
Calling package would be useless.
mvn
Reinhard Poetz napisał(a):
that's a limitation of the *Eclipse Jetty* plugin AFAICT. IIRC, if you
ignore it, everything still works.
I hope that with Torsten's help I can find out why one has to run the
app in debug mode from within Eclipse.
Ehkm, I don't use Eclipse Jetty plugin. I use
BTW, where did you get the commons-jci dependency from? Did you
build it from SVN?
Huh? Am I supposed to do this?
I just fired mvn install and got this:
Downloading: http://people.apache.org/repo/m2-snapshot-repository/
org/apache/commons/commons-jci-core/1.0-SNAPSHOT/commons-jci-
Torsten Curdt napisał(a):
Definitely! ...please use latest trunk!
No problem. Howver, root pom of commons-jci is broken, you have jci as
artifactId but it should be commons-jci.
I had to disable tests because many of them fail. Is it known issue?
Now going to test it...
--
Grzegorz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
Joerg Heinicke wrote:
We only have to ensure that the samples blocks (e.g.
cocoon-forms-samples) works with the reloading classloader plugin so
that cforms developers can easily continue their work.
??
Using the
On 02.03.2007, at 21:31, Reinhard Poetz wrote:
Joerg Heinicke wrote:
We only have to ensure that the samples blocks (e.g. cocoon-forms-
samples) works with the reloading classloader plugin so that
cforms developers can easily continue their work.
??
Using the
Reinhard Poetz napisał(a):
Using the reloading-classloader-plugin you can run a block as the
plugin creates a default Cocoon webapp and deploys the block into it.
And, as the blocks name conveys, it takes care that you can work on
Cocoon resources and Java sources while they get reloaded
29 matches
Mail list logo
