You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Antonio Petrelli <an...@gmail.com> on 2010/08/02 20:46:03 UTC
[Maven reorg] Velocity projects reorganized
Hi all
this is just to let you know that I've finished reorganizing all
Velocity projects. I left only the DocBook framework since it is not a
project, but a directory layout useful to build your documents based
on DocBook.
For produced builds see:
http://people.apache.org/builds/velocity/
A snapshot of all projects are in Maven snapshot repository.
At this point I hope to receive some feedback from you and, if you
like it, maybe we can start a vote thread to move projects from the
sandbox to the trunk.
Thanks
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Antonio Petrelli <an...@gmail.com>.
2010/9/10 Claude Brisson <cl...@renegat.net>:
> Thanks. I guess we shouldn't wait too long for the migration, otherwise the
> merge will quickly become a nightmare...
I agree but I wish that the merge process is clear for everyone (me
included :-D ).
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Claude Brisson <cl...@renegat.net>.
Thanks. I guess we shouldn't wait too long for the migration, otherwise
the merge will quickly become a nightmare...
Claude
On 10/09/2010 13:32, Antonio Petrelli wrote:
> 2010/9/10 Claude Brisson<cl...@renegat.net>:
>
>>
>>>> By the way, in which config file can one change the version number of a
>>>> dependancy?
>>>>
>>>>
>>> pom.xml, obviously. It's everything there.
>>>
>>>
>>>
>> Ok, but what if I want to replace one dependancy with a custom build of my
>> own? Let's say, for instance: I modify something in the engine and before
>> committing it I want to check whether the tools do compile with my custom
>> engine jar. What's the process?
>>
> Do a mvn install of Engine. The snapshot jars will be placed in your
> local repository (<home>/.m2/repository).
> Change dependency of Tools to the snapshot version of Engine you have built.
> Compile (or whatever you want) Tools: it will use the snapshot version.
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Antonio Petrelli <an...@gmail.com>.
2010/9/10 Claude Brisson <cl...@renegat.net>:
>
>>> By the way, in which config file can one change the version number of a
>>> dependancy?
>>>
>>
>> pom.xml, obviously. It's everything there.
>>
>>
>
> Ok, but what if I want to replace one dependancy with a custom build of my
> own? Let's say, for instance: I modify something in the engine and before
> committing it I want to check whether the tools do compile with my custom
> engine jar. What's the process?
Do a mvn install of Engine. The snapshot jars will be placed in your
local repository (<home>/.m2/repository).
Change dependency of Tools to the snapshot version of Engine you have built.
Compile (or whatever you want) Tools: it will use the snapshot version.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Claude Brisson <cl...@renegat.net>.
>> By the way, in which config file can one change the version number of a
>> dependancy?
>>
> pom.xml, obviously. It's everything there.
>
>
Ok, but what if I want to replace one dependancy with a custom build of
my own? Let's say, for instance: I modify something in the engine and
before committing it I want to check whether the tools do compile with
my custom engine jar. What's the process?
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Antonio Petrelli <an...@gmail.com>.
2010/9/10 Antonio Petrelli <an...@gmail.com>:
>> In the tools subprojects, we had very handy "start.showcase.webapp" and
>> "stop.showcase.webapp" that would start/stop the showcase webapp using Jetty
>> on the configured port. Is there any way to do it using maven?
>
> mvn cargo:start
> to start the application in a Jetty environment.
Obviously it makes sense only in "war" projects, like:
<tools-root>/velocity-tools-examples/velocity-tools-examples-showcase/
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Antonio Petrelli <an...@gmail.com>.
2010/9/10 Claude Brisson <cl...@renegat.net>:
> Webapps usually gather all their dependencies in WEB-INF/lib. Is there any
> easy way to ask maven to copy somewhere all needed jars, or at least give
> their location in maven cache? Otherwise, this should also be documented.
Yep, simple use the default scope (i.e. "compile") or, at least
"runtime" for the dependency.
> By the way, in which config file can one change the version number of a
> dependancy?
pom.xml, obviously. It's everything there.
> In the tools subprojects, we had very handy "start.showcase.webapp" and
> "stop.showcase.webapp" that would start/stop the showcase webapp using Jetty
> on the configured port. Is there any way to do it using maven?
mvn cargo:start
to start the application in a Jetty environment.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Claude Brisson <cl...@renegat.net>.
Ok, it seems to works. Engine and tools do compile.
Some questions remaining:
Webapps usually gather all their dependencies in WEB-INF/lib. Is there
any easy way to ask maven to copy somewhere all needed jars, or at least
give their location in maven cache? Otherwise, this should also be
documented.
By the way, in which config file can one change the version number of a
dependancy?
In the tools subprojects, we had very handy "start.showcase.webapp" and
"stop.showcase.webapp" that would start/stop the showcase webapp using
Jetty on the configured port. Is there any way to do it using maven?
Claude
On 09/09/2010 23:31, Nathan Bubna wrote:
> ant -p is needed because targets are always custom. Maven goals are
> standardized, so users are expected to know the basics :
> http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
>
> mvn install is usually where i begin.
>
> maven has dependency management at the core. getting dependencies is
> the first thing it tries to do. if it can't find them, then it stops.
> one very useful part of moving to maven is that we can have a master
> pom that saves us from repeating common project info in all of our
> projects. of course, that means all projects have the master pom as a
> dependency. so, until we publicly release a velocity master pom, you
> will have to locally install it before you can build any of these
> refactored projects. the master pom project is at:
>
> https://svn.apache.org/repos/asf/velocity/sandbox/maven-reorg/maven/trunk/pom
>
> check that out and do a "mvn install" there, then go try the engine
> project again.
>
> of course, all of this will need to be documented once it moves into
> our active dev branches/trunks.
>
> On Thu, Sep 9, 2010 at 1:28 PM, Claude Brisson<cl...@renegat.net> wrote:
>
>> I checked out the sandbox and changed directory to
>> sandbox/maven-reorg/engine/trunk. Once there, I look into the Readme.txt.
>> Bad luck, it still does reference "ant".
>> Ok. I recall something about invoking maven with an "mvn" command...
>>
>> I first try a mvn --help ; nothing in the given options tells me how to
>> obtain a list of valid build goals/phases (like the standardized and very
>> handy "ant -p").
>>
>> Ok, I tried "mvn" without any argument, and got:
>>
>>
>> [INFO] Scanning for projects...
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] FATAL ERROR
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Error building POM (may not be this project's POM).
>>
>>
>> Project ID:
>> org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT
>>
>> Reason: Cannot find parent: org.apache.velocity:velocity-master for
>> project:
>> org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT for
>> project org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT
>>
>>
>>
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Trace
>> org.apache.maven.reactor.MavenExecutionException: Cannot find
>> parent: org.apache.velocity:velocity-master for project:
>> org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT for
>> project org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT
>> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
>> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
>> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>>
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at
>> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>> at
>> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
>> Caused by: org.apache.maven.project.ProjectBuildingException: Cannot
>> find parent: org.apache.velocity:velocity-master for project:
>> org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT for
>> project org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT
>> at
>>
>> org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1370)
>> at
>>
>> org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:821)
>> at
>>
>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
>> at
>>
>> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
>> at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
>> at
>> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
>> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
>> ... 11 more
>> Caused by: org.apache.maven.project.ProjectBuildingException: POM
>> 'org.apache.velocity:velocity-master' not found in repository:
>> Unable to download the artifact from any repository
>>
>> org.apache.velocity:velocity-master:pom:1-SNAPSHOT
>>
>> from the specified remote repositories:
>> central (http://repo1.maven.org/maven2)
>> for project org.apache.velocity:velocity-master
>> at
>>
>> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:603)
>> at
>>
>> org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1366)
>> ... 17 more
>> Caused by:
>> org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable
>> to download the artifact from any repository
>>
>> org.apache.velocity:velocity-master:pom:1-SNAPSHOT
>>
>> from the specified remote repositories:
>> central (http://repo1.maven.org/maven2)
>>
>> at
>>
>> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:212)
>> at
>>
>> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:74)
>> at
>>
>> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:556)
>> ... 18 more
>> Caused by: org.apache.maven.wagon.ResourceDoesNotExistException:
>> Unable to download the artifact from any repository
>> at
>>
>> org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:331)
>> at
>>
>> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:200)
>> ... 20 more
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Total time:< 1 second
>> [INFO] Finished at: Thu Sep 09 22:13:32 CEST 2010
>> [INFO] Final Memory: 1M/50M
>> [INFO]
>> ------------------------------------------------------------------------
>>
>>
>> Same result with the tools subproject.
>>
>> So I guess the maven build does not yet work out-of-the-box...
>>
>> Also, I would like to understand why it was needed to split the source-tree
>> in so many sub-modules. Can't the build system figure out which sources are
>> needed for such or such target?
>>
>>
>> Claude
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail:dev-help@velocity.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Nathan Bubna <nb...@gmail.com>.
ant -p is needed because targets are always custom. Maven goals are
standardized, so users are expected to know the basics :
http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
mvn install is usually where i begin.
maven has dependency management at the core. getting dependencies is
the first thing it tries to do. if it can't find them, then it stops.
one very useful part of moving to maven is that we can have a master
pom that saves us from repeating common project info in all of our
projects. of course, that means all projects have the master pom as a
dependency. so, until we publicly release a velocity master pom, you
will have to locally install it before you can build any of these
refactored projects. the master pom project is at:
https://svn.apache.org/repos/asf/velocity/sandbox/maven-reorg/maven/trunk/pom
check that out and do a "mvn install" there, then go try the engine
project again.
of course, all of this will need to be documented once it moves into
our active dev branches/trunks.
On Thu, Sep 9, 2010 at 1:28 PM, Claude Brisson <cl...@renegat.net> wrote:
> I checked out the sandbox and changed directory to
> sandbox/maven-reorg/engine/trunk. Once there, I look into the Readme.txt.
> Bad luck, it still does reference "ant".
> Ok. I recall something about invoking maven with an "mvn" command...
>
> I first try a mvn --help ; nothing in the given options tells me how to
> obtain a list of valid build goals/phases (like the standardized and very
> handy "ant -p").
>
> Ok, I tried "mvn" without any argument, and got:
>
>
> [INFO] Scanning for projects...
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] FATAL ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Error building POM (may not be this project's POM).
>
>
> Project ID:
> org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT
>
> Reason: Cannot find parent: org.apache.velocity:velocity-master for
> project:
> org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT for
> project org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT
>
>
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Trace
> org.apache.maven.reactor.MavenExecutionException: Cannot find
> parent: org.apache.velocity:velocity-master for project:
> org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT for
> project org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.project.ProjectBuildingException: Cannot
> find parent: org.apache.velocity:velocity-master for project:
> org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT for
> project org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT
> at
>
> org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1370)
> at
>
> org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:821)
> at
>
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
> at
>
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
> at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
> at
> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
> ... 11 more
> Caused by: org.apache.maven.project.ProjectBuildingException: POM
> 'org.apache.velocity:velocity-master' not found in repository:
> Unable to download the artifact from any repository
>
> org.apache.velocity:velocity-master:pom:1-SNAPSHOT
>
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> for project org.apache.velocity:velocity-master
> at
>
> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:603)
> at
>
> org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1366)
> ... 17 more
> Caused by:
> org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable
> to download the artifact from any repository
>
> org.apache.velocity:velocity-master:pom:1-SNAPSHOT
>
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
>
> at
>
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:212)
> at
>
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:74)
> at
>
> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:556)
> ... 18 more
> Caused by: org.apache.maven.wagon.ResourceDoesNotExistException:
> Unable to download the artifact from any repository
> at
>
> org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:331)
> at
>
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:200)
> ... 20 more
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: < 1 second
> [INFO] Finished at: Thu Sep 09 22:13:32 CEST 2010
> [INFO] Final Memory: 1M/50M
> [INFO]
> ------------------------------------------------------------------------
>
>
> Same result with the tools subproject.
>
> So I guess the maven build does not yet work out-of-the-box...
>
> Also, I would like to understand why it was needed to split the source-tree
> in so many sub-modules. Can't the build system figure out which sources are
> needed for such or such target?
>
>
> Claude
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Claude Brisson <cl...@renegat.net>.
I checked out the sandbox and changed directory to
sandbox/maven-reorg/engine/trunk. Once there, I look into the
Readme.txt. Bad luck, it still does reference "ant".
Ok. I recall something about invoking maven with an "mvn" command...
I first try a mvn --help ; nothing in the given options tells me how to
obtain a list of valid build goals/phases (like the standardized and
very handy "ant -p").
Ok, I tried "mvn" without any argument, and got:
[INFO] Scanning for projects...
[INFO]
------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Project ID:
org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT
Reason: Cannot find parent: org.apache.velocity:velocity-master for
project:
org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT for
project org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT
[INFO]
------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Cannot find
parent: org.apache.velocity:velocity-master for project:
org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT for
project org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.ProjectBuildingException: Cannot
find parent: org.apache.velocity:velocity-master for project:
org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT for
project org.apache.velocity:velocity-engine-parent:pom:2.0.0-SNAPSHOT
at
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1370)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:821)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
at
org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
... 11 more
Caused by: org.apache.maven.project.ProjectBuildingException: POM
'org.apache.velocity:velocity-master' not found in repository:
Unable to download the artifact from any repository
org.apache.velocity:velocity-master:pom:1-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
for project org.apache.velocity:velocity-master
at
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:603)
at
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1366)
... 17 more
Caused by:
org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable
to download the artifact from any repository
org.apache.velocity:velocity-master:pom:1-SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:212)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:74)
at
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:556)
... 18 more
Caused by: org.apache.maven.wagon.ResourceDoesNotExistException:
Unable to download the artifact from any repository
at
org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:331)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:200)
... 20 more
[INFO]
------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Thu Sep 09 22:13:32 CEST 2010
[INFO] Final Memory: 1M/50M
[INFO]
------------------------------------------------------------------------
Same result with the tools subproject.
So I guess the maven build does not yet work out-of-the-box...
Also, I would like to understand why it was needed to split the
source-tree in so many sub-modules. Can't the build system figure out
which sources are needed for such or such target?
Claude
Re: [Maven reorg] Velocity projects reorganized
Posted by Nathan Bubna <nb...@gmail.com>.
On Fri, Sep 10, 2010 at 3:18 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2010/9/9 Nathan Bubna <nb...@gmail.com>:
>> On Thu, Sep 9, 2010 at 12:27 AM, Antonio Petrelli
>> <an...@gmail.com> wrote:
>>> 2010/9/8 Nathan Bubna <nb...@gmail.com>:
>>>> 2) Merge sandboxed Engine project(s) into the 2.x branch of Engine
>>>> 3) Copy trunks of current projects into maintenance branches (e.g.
>>>> 2.0.x branch for Tools)
>>>> 4) Merge other sandboxed projects into their respective project trunks
>>>>
>>>> and i only say merge so that changes in the various trunks/branches
>>>> that happened since you copied things off to the sandbox are not lost.
>>>> i know there have been some Engine 2.x changes at least. i can't
>>>> recall if Tools changed in that time.
>>>
>>> No, because classes are moved around in various places and in various
>>> subdirectories that it would be too difficult (impossible?) to merge.
>>
>> there aren't that many changes to Engine 2 and Tools 2 since you
>> forked, and they need to be merged in one way or another. it doesn't
>> have to be svn merge.
>
> I try to explain it better (note that I mean svn merge, and yes, it
> has to be it).
> Merging from the current branch to the sandbox is *easy*, the only
> difficulty is finding the correct source root, since some classes have
> been moved from the main projects to submodules.
> Merging from the sandbox to the branch is *difficult*, because SVN is
> not so smart at identifying code movements. I mean, the merge
> (ideally) should port the fact that a piece of code *moved*.
>
> So I would like to (svn) merge from the branch to the sandbox and then
> moving the branch to archive and move the sandboxed project to the
> place where the branch was.
That sounds fine to me. I just wanted to be sure that recent work was
not lost. :)
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Antonio Petrelli <an...@gmail.com>.
2010/9/9 Nathan Bubna <nb...@gmail.com>:
> On Thu, Sep 9, 2010 at 12:27 AM, Antonio Petrelli
> <an...@gmail.com> wrote:
>> 2010/9/8 Nathan Bubna <nb...@gmail.com>:
>>> 2) Merge sandboxed Engine project(s) into the 2.x branch of Engine
>>> 3) Copy trunks of current projects into maintenance branches (e.g.
>>> 2.0.x branch for Tools)
>>> 4) Merge other sandboxed projects into their respective project trunks
>>>
>>> and i only say merge so that changes in the various trunks/branches
>>> that happened since you copied things off to the sandbox are not lost.
>>> i know there have been some Engine 2.x changes at least. i can't
>>> recall if Tools changed in that time.
>>
>> No, because classes are moved around in various places and in various
>> subdirectories that it would be too difficult (impossible?) to merge.
>
> there aren't that many changes to Engine 2 and Tools 2 since you
> forked, and they need to be merged in one way or another. it doesn't
> have to be svn merge.
I try to explain it better (note that I mean svn merge, and yes, it
has to be it).
Merging from the current branch to the sandbox is *easy*, the only
difficulty is finding the correct source root, since some classes have
been moved from the main projects to submodules.
Merging from the sandbox to the branch is *difficult*, because SVN is
not so smart at identifying code movements. I mean, the merge
(ideally) should port the fact that a piece of code *moved*.
So I would like to (svn) merge from the branch to the sandbox and then
moving the branch to archive and move the sandboxed project to the
place where the branch was.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Nathan Bubna <nb...@gmail.com>.
On Thu, Sep 9, 2010 at 12:27 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2010/9/8 Nathan Bubna <nb...@gmail.com>:
>> 2) Merge sandboxed Engine project(s) into the 2.x branch of Engine
>> 3) Copy trunks of current projects into maintenance branches (e.g.
>> 2.0.x branch for Tools)
>> 4) Merge other sandboxed projects into their respective project trunks
>>
>> and i only say merge so that changes in the various trunks/branches
>> that happened since you copied things off to the sandbox are not lost.
>> i know there have been some Engine 2.x changes at least. i can't
>> recall if Tools changed in that time.
>
> No, because classes are moved around in various places and in various
> subdirectories that it would be too difficult (impossible?) to merge.
there aren't that many changes to Engine 2 and Tools 2 since you
forked, and they need to be merged in one way or another. it doesn't
have to be svn merge.
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Antonio Petrelli <an...@gmail.com>.
2010/9/8 Nathan Bubna <nb...@gmail.com>:
> 2) Merge sandboxed Engine project(s) into the 2.x branch of Engine
> 3) Copy trunks of current projects into maintenance branches (e.g.
> 2.0.x branch for Tools)
> 4) Merge other sandboxed projects into their respective project trunks
>
> and i only say merge so that changes in the various trunks/branches
> that happened since you copied things off to the sandbox are not lost.
> i know there have been some Engine 2.x changes at least. i can't
> recall if Tools changed in that time.
No, because classes are moved around in various places and in various
subdirectories that it would be too difficult (impossible?) to merge.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Nathan Bubna <nb...@gmail.com>.
On Wed, Sep 8, 2010 at 12:59 PM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2010/9/8 Nathan Bubna <nb...@gmail.com>:
>> On Wed, Sep 8, 2010 at 12:36 PM, Antonio Petrelli
>> <an...@gmail.com> wrote:
>>> 2010/9/8 Nathan Bubna <nb...@gmail.com>:
>>>> No, we're not definitely not mavenizing the Engine trunk, only the 2.x
>>>> branch (which can probably lose the "exp" moniker by now). Also, we
>>>> should not mavenize the Tools trunk, but create a 2.1.x branch for
>>>> that. The trunk is probably fine for the rest the projects.
>>>
>>> For me it's essentially the same, as long as we schedule the move to a
>>> correct codebase management, i.e. trunk for the most advanced
>>> codebase, branches for maintenance.
>>
>> a good point, though the Engine trunk is not maintenance (yet), it's
>> 1.x development, at least until 1.7 final is out. after that, we can
>> see if anyone wants to develop a 1.8 or not. but for Tools, i
>> concede. The trunk should be copied to a 2.0.x branch and then
>> upgraded to 2.1-SNAPSHOT for mavenization.
>
> So do you think I can rephrase this way?
> 2. Move "trunk" of Tools to a maintenance branch.
> 3. Move non mavenized projects (2.x branch of Engine, 2.1.x branch of
> Tools, "trunk" for the rest) to archive.
> 4. Move sandboxed projects in the place of the 2.x branch of Engine
> and "trunk" for the rest.
why not just this?
2) Merge sandboxed Engine project(s) into the 2.x branch of Engine
3) Copy trunks of current projects into maintenance branches (e.g.
2.0.x branch for Tools)
4) Merge other sandboxed projects into their respective project trunks
and i only say merge so that changes in the various trunks/branches
that happened since you copied things off to the sandbox are not lost.
i know there have been some Engine 2.x changes at least. i can't
recall if Tools changed in that time.
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Antonio Petrelli <an...@gmail.com>.
2010/9/8 Nathan Bubna <nb...@gmail.com>:
> On Wed, Sep 8, 2010 at 12:36 PM, Antonio Petrelli
> <an...@gmail.com> wrote:
>> 2010/9/8 Nathan Bubna <nb...@gmail.com>:
>>> No, we're not definitely not mavenizing the Engine trunk, only the 2.x
>>> branch (which can probably lose the "exp" moniker by now). Also, we
>>> should not mavenize the Tools trunk, but create a 2.1.x branch for
>>> that. The trunk is probably fine for the rest the projects.
>>
>> For me it's essentially the same, as long as we schedule the move to a
>> correct codebase management, i.e. trunk for the most advanced
>> codebase, branches for maintenance.
>
> a good point, though the Engine trunk is not maintenance (yet), it's
> 1.x development, at least until 1.7 final is out. after that, we can
> see if anyone wants to develop a 1.8 or not. but for Tools, i
> concede. The trunk should be copied to a 2.0.x branch and then
> upgraded to 2.1-SNAPSHOT for mavenization.
So do you think I can rephrase this way?
2. Move "trunk" of Tools to a maintenance branch.
3. Move non mavenized projects (2.x branch of Engine, 2.1.x branch of
Tools, "trunk" for the rest) to archive.
4. Move sandboxed projects in the place of the 2.x branch of Engine
and "trunk" for the rest.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Nathan Bubna <nb...@gmail.com>.
On Wed, Sep 8, 2010 at 12:36 PM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2010/9/8 Nathan Bubna <nb...@gmail.com>:
>> No, we're not definitely not mavenizing the Engine trunk, only the 2.x
>> branch (which can probably lose the "exp" moniker by now). Also, we
>> should not mavenize the Tools trunk, but create a 2.1.x branch for
>> that. The trunk is probably fine for the rest the projects.
>
> For me it's essentially the same, as long as we schedule the move to a
> correct codebase management, i.e. trunk for the most advanced
> codebase, branches for maintenance.
a good point, though the Engine trunk is not maintenance (yet), it's
1.x development, at least until 1.7 final is out. after that, we can
see if anyone wants to develop a 1.8 or not. but for Tools, i
concede. The trunk should be copied to a 2.0.x branch and then
upgraded to 2.1-SNAPSHOT for mavenization.
> So I can rephrase the 2 and 3 points this way:
> 2. Move non mavenized projects (2.x branch of Engine, 2.1.x branch of
> Tools, "trunk" for the rest) to archive.
> 3. Move sandboxed projects in the place of the branches and trunks
> archived at point 2.
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Antonio Petrelli <an...@gmail.com>.
2010/9/8 Nathan Bubna <nb...@gmail.com>:
> No, we're not definitely not mavenizing the Engine trunk, only the 2.x
> branch (which can probably lose the "exp" moniker by now). Also, we
> should not mavenize the Tools trunk, but create a 2.1.x branch for
> that. The trunk is probably fine for the rest the projects.
For me it's essentially the same, as long as we schedule the move to a
correct codebase management, i.e. trunk for the most advanced
codebase, branches for maintenance.
So I can rephrase the 2 and 3 points this way:
2. Move non mavenized projects (2.x branch of Engine, 2.1.x branch of
Tools, "trunk" for the rest) to archive.
3. Move sandboxed projects in the place of the branches and trunks
archived at point 2.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Nathan Bubna <nb...@gmail.com>.
No, we're not definitely not mavenizing the Engine trunk, only the 2.x
branch (which can probably lose the "exp" moniker by now). Also, we
should not mavenize the Tools trunk, but create a 2.1.x branch for
that. The trunk is probably fine for the rest the projects.
On Wed, Sep 8, 2010 at 12:18 PM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2010/9/8 Nathan Bubna <nb...@gmail.com>:
>> Well, since no one else seems to have an opinion, we can either a)
>> assume they have no objections and procede or b) call for a vote to
>> get attention and decide by lazy consensus (at least one +1 and no -1)
>>
>> personally, i'm ok with either next step. :)
>
> I prefer the latter, so if anyone has an objection it can be his last word.
> This could be the vote thread stub.
>
> <stub>
> Subject:[VOTE] Promote mavenized Velocity projects to trunk
>
> Body:
> All Velocity projects, with the exclusion of DBF, have been mavenized.
> You can see the result of this process in the Subversion sandbox:
> http://svn.apache.org/repos/asf/velocity/sandbox/maven-reorg/
>
> The promotion process will be:
> 1. Merge recent changes in the official codebase in the sandboxed projects.
> 2. Move non mavenized projects to archive.
> 3. Move sandboxed projects to main development trunks.
>
> Please cast your vote about promoting these mavenized projects to the
> main trunk of development.
> +1: yes, let's promote them;
> -1: no, because...
> +0: neutral, with a tendence to agree to promotion;
> -0: neutral, with a tendence to disagree.
>
> Everybody is welcome to cast his vote. Votes from PMC members are binding.
> The vote passes if there is at least one binding +1 and no binding -1.
> </stub>
>
> Can I proceed?
>
> Thanks
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Antonio Petrelli <an...@gmail.com>.
2010/9/8 Nathan Bubna <nb...@gmail.com>:
> Well, since no one else seems to have an opinion, we can either a)
> assume they have no objections and procede or b) call for a vote to
> get attention and decide by lazy consensus (at least one +1 and no -1)
>
> personally, i'm ok with either next step. :)
I prefer the latter, so if anyone has an objection it can be his last word.
This could be the vote thread stub.
<stub>
Subject:[VOTE] Promote mavenized Velocity projects to trunk
Body:
All Velocity projects, with the exclusion of DBF, have been mavenized.
You can see the result of this process in the Subversion sandbox:
http://svn.apache.org/repos/asf/velocity/sandbox/maven-reorg/
The promotion process will be:
1. Merge recent changes in the official codebase in the sandboxed projects.
2. Move non mavenized projects to archive.
3. Move sandboxed projects to main development trunks.
Please cast your vote about promoting these mavenized projects to the
main trunk of development.
+1: yes, let's promote them;
-1: no, because...
+0: neutral, with a tendence to agree to promotion;
-0: neutral, with a tendence to disagree.
Everybody is welcome to cast his vote. Votes from PMC members are binding.
The vote passes if there is at least one binding +1 and no binding -1.
</stub>
Can I proceed?
Thanks
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Nathan Bubna <nb...@gmail.com>.
Well, since no one else seems to have an opinion, we can either a)
assume they have no objections and procede or b) call for a vote to
get attention and decide by lazy consensus (at least one +1 and no -1)
personally, i'm ok with either next step. :)
On Mon, Aug 30, 2010 at 6:23 PM, Nathan Bubna <nb...@gmail.com> wrote:
> On Mon, Aug 2, 2010 at 11:46 AM, Antonio Petrelli
> <an...@gmail.com> wrote:
>> Hi all
>> this is just to let you know that I've finished reorganizing all
>> Velocity projects. I left only the DocBook framework since it is not a
>> project, but a directory layout useful to build your documents based
>> on DocBook.
>> For produced builds see:
>> http://people.apache.org/builds/velocity/
>>
>> A snapshot of all projects are in Maven snapshot repository.
>>
>> At this point I hope to receive some feedback from you and, if you
>> like it, maybe we can start a vote thread to move projects from the
>> sandbox to the trunk.
>
> Ok, summer is nuts. I'm finally digging into a lot of old velocity
> todo stuff, including this. I've been running the maven-reorg builds
> and poking around at them. For the most part, i like it. It will
> certainly take some getting used to though, and i'm still fairly wary
> of complicated Maven stuff after all my frustration with the
> velocity-site mess. But at this point, you'll have my support in a
> vote for moving this into the Engine 2.0, Tools 2.1, etc, with one
> condition: documentation. With the proliferation of artifacts and
> their various reasons and dependencies, we need some very
> user-friendly "Which Jar Is For Me?" type of documentation for users.
> We also need to be sure that you aren't the only one who understands
> how this customized, complicated Maven build works. And finally, i
> don't know if maven can do this, but one of my current favorite parts
> of the Velocity and VelocityTools build files is that they spit out
> customized directions for building and publishing releases right along
> with the target output, including what documentation to be sure and
> update. That really helps to keep me on track when i'm doing
> releases.
>
> Also, i'm curious whether any of these builds include OSGi manifest
> creation? That's a recent addition to some of our builds (just engine
> and tools at this point, i think), that i don't want to lose.
>
> All in all, this is great work, and i'm excited to see us move in a
> more standard direction for our next versions. I am very sorry that
> it took me so long to respond, and i hope you aren't too discouraged
> that no one else has responded yet. It's a big thing to consider and
> hard to comment intelligently without putting in a lot of time. Good
> documentation to read over that explains how/what is going on with all
> the poms and such would probably help get more response, but i know
> you've put in a lot of work already.
>
> So, seriously, what do the rest of you guys think? We've long talked
> about perhaps doing this in 2.0. Should we fire up an official vote
> thread or just voice support here? Henning, i know you are planning
> to work on fixing velocity-site, does any of this help? hinder?
>
>> Thanks
>> Antonio
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: dev-help@velocity.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Nathan Bubna <nb...@gmail.com>.
On Tue, Aug 31, 2010 at 11:53 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2010/8/31 Nathan Bubna <nb...@gmail.com>:
>>>> And finally, i
>>>> don't know if maven can do this, but one of my current favorite parts
>>>> of the Velocity and VelocityTools build files is that they spit out
>>>> customized directions for building and publishing releases right along
>>>> with the target output, including what documentation to be sure and
>>>> update. That really helps to keep me on track when i'm doing
>>>> releases.
>>>
>>> Can you make an example, or tell me where to see? I missed this point.
>>
>> sure, in Engine, call the ant release.howto and publish.howto targets
>
> Ah echos! It is possible with... Antrun plugin! :-D
works for me :)
> Anyway, reading the readme.howto directions, most of them are
> automatically done when calling:
> mvn release:prepare
> and
> mvn release:perform
> In particular, tagging, signing, moving to the next version,
> publishing to Nexus and to people.apache.org are automatically done.
most, but not all.
> RAT check can be attached, if we want.
that would be good.
> Anyway, what difference do you see in reading this text and reading an
> HTML page like this?
> http://tiles.apache.org/framework/dev/release.html
yeah, the Tiles release page is great, but one requires me to go look,
the other is spit out in front of my face. the page is great for
details and full info, the echo is great for reminding. not
essential, but very helpful.
>>>> Also, i'm curious whether any of these builds include OSGi manifest
>>>> creation? That's a recent addition to some of our builds (just engine
>>>> and tools at this point, i think), that i don't want to lose.
>>>
>>> It is possible (I've already done it with Tiles) however I forgot to put it.
>>> Did you publish any of these OSGi-ready packages, so I can configure
>>> the plugin correctly?
>>
>> yeah, i think both Engine 1.6.4 and 1.7-beta1 supported it, though
>> with different techniques, IIRC. The Engine's build uses Spring's
>> Bundlor ant task for it. I think some osgi stuff was in Tools 2 also.
>
> Sorry to contradict you, but I see it only in 1.7-beta1. Anyway it is
> pretty straightforward, it's easy to configure with the Maven Felix
> plugin.
oh, don't ever apologize for contradicting me. i like facts better
than my opinions. :)
> Thanks
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Antonio Petrelli <an...@gmail.com>.
2010/8/31 Nathan Bubna <nb...@gmail.com>:
>>> And finally, i
>>> don't know if maven can do this, but one of my current favorite parts
>>> of the Velocity and VelocityTools build files is that they spit out
>>> customized directions for building and publishing releases right along
>>> with the target output, including what documentation to be sure and
>>> update. That really helps to keep me on track when i'm doing
>>> releases.
>>
>> Can you make an example, or tell me where to see? I missed this point.
>
> sure, in Engine, call the ant release.howto and publish.howto targets
Ah echos! It is possible with... Antrun plugin! :-D
Anyway, reading the readme.howto directions, most of them are
automatically done when calling:
mvn release:prepare
and
mvn release:perform
In particular, tagging, signing, moving to the next version,
publishing to Nexus and to people.apache.org are automatically done.
RAT check can be attached, if we want.
Anyway, what difference do you see in reading this text and reading an
HTML page like this?
http://tiles.apache.org/framework/dev/release.html
>>> Also, i'm curious whether any of these builds include OSGi manifest
>>> creation? That's a recent addition to some of our builds (just engine
>>> and tools at this point, i think), that i don't want to lose.
>>
>> It is possible (I've already done it with Tiles) however I forgot to put it.
>> Did you publish any of these OSGi-ready packages, so I can configure
>> the plugin correctly?
>
> yeah, i think both Engine 1.6.4 and 1.7-beta1 supported it, though
> with different techniques, IIRC. The Engine's build uses Spring's
> Bundlor ant task for it. I think some osgi stuff was in Tools 2 also.
Sorry to contradict you, but I see it only in 1.7-beta1. Anyway it is
pretty straightforward, it's easy to configure with the Maven Felix
plugin.
Thanks
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Nathan Bubna <nb...@gmail.com>.
On Tue, Aug 31, 2010 at 12:37 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2010/8/31 Nathan Bubna <nb...@gmail.com>:
>> But at this point, you'll have my support in a
>> vote for moving this into the Engine 2.0, Tools 2.1, etc, with one
>> condition: documentation. With the proliferation of artifacts and
>> their various reasons and dependencies, we need some very
>> user-friendly "Which Jar Is For Me?" type of documentation for users.
>
> Ok I will work on it.
cool, but i'd wait for consensus on moving this way before you put in
more work on it.
>> We also need to be sure that you aren't the only one who understands
>> how this customized, complicated Maven build works.
>
> This is fairly standard, the "complication" is only in the number of artifacts.
> OTOH I must say that Ant builds are much more complicated when seen
> for the first time, because everyone uses his style of coding.
that's good to hear!
>> And finally, i
>> don't know if maven can do this, but one of my current favorite parts
>> of the Velocity and VelocityTools build files is that they spit out
>> customized directions for building and publishing releases right along
>> with the target output, including what documentation to be sure and
>> update. That really helps to keep me on track when i'm doing
>> releases.
>
> Can you make an example, or tell me where to see? I missed this point.
sure, in Engine, call the ant release.howto and publish.howto targets
>> Also, i'm curious whether any of these builds include OSGi manifest
>> creation? That's a recent addition to some of our builds (just engine
>> and tools at this point, i think), that i don't want to lose.
>
> It is possible (I've already done it with Tiles) however I forgot to put it.
> Did you publish any of these OSGi-ready packages, so I can configure
> the plugin correctly?
yeah, i think both Engine 1.6.4 and 1.7-beta1 supported it, though
with different techniques, IIRC. The Engine's build uses Spring's
Bundlor ant task for it. I think some osgi stuff was in Tools 2 also.
>> All in all, this is great work, and i'm excited to see us move in a
>> more standard direction for our next versions. I am very sorry that
>> it took me so long to respond, and i hope you aren't too discouraged
>> that no one else has responded yet.
>
> No problem, when I've nothing to do, there's Tiles that keeps me busy :-P
:)
> Thanks
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Antonio Petrelli <an...@gmail.com>.
2010/8/31 Nathan Bubna <nb...@gmail.com>:
> But at this point, you'll have my support in a
> vote for moving this into the Engine 2.0, Tools 2.1, etc, with one
> condition: documentation. With the proliferation of artifacts and
> their various reasons and dependencies, we need some very
> user-friendly "Which Jar Is For Me?" type of documentation for users.
Ok I will work on it.
> We also need to be sure that you aren't the only one who understands
> how this customized, complicated Maven build works.
This is fairly standard, the "complication" is only in the number of artifacts.
OTOH I must say that Ant builds are much more complicated when seen
for the first time, because everyone uses his style of coding.
> And finally, i
> don't know if maven can do this, but one of my current favorite parts
> of the Velocity and VelocityTools build files is that they spit out
> customized directions for building and publishing releases right along
> with the target output, including what documentation to be sure and
> update. That really helps to keep me on track when i'm doing
> releases.
Can you make an example, or tell me where to see? I missed this point.
> Also, i'm curious whether any of these builds include OSGi manifest
> creation? That's a recent addition to some of our builds (just engine
> and tools at this point, i think), that i don't want to lose.
It is possible (I've already done it with Tiles) however I forgot to put it.
Did you publish any of these OSGi-ready packages, so I can configure
the plugin correctly?
> All in all, this is great work, and i'm excited to see us move in a
> more standard direction for our next versions. I am very sorry that
> it took me so long to respond, and i hope you aren't too discouraged
> that no one else has responded yet.
No problem, when I've nothing to do, there's Tiles that keeps me busy :-P
Thanks
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: [Maven reorg] Velocity projects reorganized
Posted by Nathan Bubna <nb...@gmail.com>.
On Mon, Aug 2, 2010 at 11:46 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> Hi all
> this is just to let you know that I've finished reorganizing all
> Velocity projects. I left only the DocBook framework since it is not a
> project, but a directory layout useful to build your documents based
> on DocBook.
> For produced builds see:
> http://people.apache.org/builds/velocity/
>
> A snapshot of all projects are in Maven snapshot repository.
>
> At this point I hope to receive some feedback from you and, if you
> like it, maybe we can start a vote thread to move projects from the
> sandbox to the trunk.
Ok, summer is nuts. I'm finally digging into a lot of old velocity
todo stuff, including this. I've been running the maven-reorg builds
and poking around at them. For the most part, i like it. It will
certainly take some getting used to though, and i'm still fairly wary
of complicated Maven stuff after all my frustration with the
velocity-site mess. But at this point, you'll have my support in a
vote for moving this into the Engine 2.0, Tools 2.1, etc, with one
condition: documentation. With the proliferation of artifacts and
their various reasons and dependencies, we need some very
user-friendly "Which Jar Is For Me?" type of documentation for users.
We also need to be sure that you aren't the only one who understands
how this customized, complicated Maven build works. And finally, i
don't know if maven can do this, but one of my current favorite parts
of the Velocity and VelocityTools build files is that they spit out
customized directions for building and publishing releases right along
with the target output, including what documentation to be sure and
update. That really helps to keep me on track when i'm doing
releases.
Also, i'm curious whether any of these builds include OSGi manifest
creation? That's a recent addition to some of our builds (just engine
and tools at this point, i think), that i don't want to lose.
All in all, this is great work, and i'm excited to see us move in a
more standard direction for our next versions. I am very sorry that
it took me so long to respond, and i hope you aren't too discouraged
that no one else has responded yet. It's a big thing to consider and
hard to comment intelligently without putting in a lot of time. Good
documentation to read over that explains how/what is going on with all
the poms and such would probably help get more response, but i know
you've put in a lot of work already.
So, seriously, what do the rest of you guys think? We've long talked
about perhaps doing this in 2.0. Should we fire up an official vote
thread or just voice support here? Henning, i know you are planning
to work on fixing velocity-site, does any of this help? hinder?
> Thanks
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org