jamon-hackers — Discussion list for jamon developers

[Jamon-hackers] Slow incremental Eclipse builder builds?

[Philip Z. <ph...@cl...>]

Hi there,

Over time, our Jamon Template Builder in Eclipse has gotten slower and
slower.  A little bit of analysis suggests that a lot of time is being
spent in creating the ProjectClassLoader in TemplateBuilder$BuildVisitor's
constructor.

        at
org.jamon.eclipse.ProjectClassLoader.<init>(ProjectClassLoader.java:29)
        at
org.jamon.eclipse.TemplateBuilder$BuildVisitor.<init>(TemplateBuilder.java:220)

It looks like BuildVisitor is created at every incremental build, and
Eclipse is taking its merry time enumerating our very many dependencies.
 (strace shows Eclipse 'stat'ing all the .m2repo jars, and parsing URLs)

I'm tempted to cache ProjectClassLoader, but I've not worked with Eclipse
builders enough to know whether that's a startlingly bad idea.  Presumably
I'd need to invalidate the cache any time the project dependencies changed,
and I'm not quite sure how I'd pick up on that.

Thoughts?  Anyone experienced similar slowness?

Thanks!

-- Philip


Here's a sample stack trace:


"Worker-73" prio=10 tid=0x00007fc5704a4800 nid=0x2779 runnable
[0x00007fc51c461000]
   java.lang.Thread.State: RUNNABLE
        at
org.eclipse.core.internal.resources.WorkspaceRoot.getProject(WorkspaceRoot.java:180)
        at
org.eclipse.core.internal.resources.Workspace.newResource(Workspace.java:2173)
        at
org.eclipse.core.internal.resources.Container.getChildren(Container.java:154)
        at
org.eclipse.core.internal.resources.WorkspaceRoot.getProjects(WorkspaceRoot.java:214)
        at
org.eclipse.core.internal.localstore.FileSystemResourceManager.allPathsForLocationNonCanonical(FileSystemResourceManager.java:79)
        at
org.eclipse.core.internal.localstore.FileSystemResourceManager.allPathsForLocation(FileSystemResourceManager.java:62)
        at
org.eclipse.core.internal.localstore.FileSystemResourceManager.allResourcesFor(FileSystemResourceManager.java:216)
        at
org.eclipse.core.internal.resources.WorkspaceRoot.findContainersForLocationURI(WorkspaceRoot.java:89)
        at
org.eclipse.core.internal.resources.WorkspaceRoot.findContainersForLocationURI(WorkspaceRoot.java:80)
        at
org.eclipse.core.internal.resources.WorkspaceRoot.findContainersForLocation(WorkspaceRoot.java:73)
        at
org.eclipse.jdt.internal.launching.RuntimeClasspathEntry.getResource(RuntimeClasspathEntry.java:332)
        at
org.eclipse.jdt.internal.launching.RuntimeClasspathEntry.resolveToOSPath(RuntimeClasspathEntry.java:460)
        at
org.eclipse.jdt.internal.launching.RuntimeClasspathEntry.getLocation(RuntimeClasspathEntry.java:449)
        at
org.eclipse.jdt.launching.JavaRuntime.computeDefaultRuntimeClassPath(JavaRuntime.java:1397)
        at
org.jamon.eclipse.ProjectClassLoader.classpathUrlsForProject(ProjectClassLoader.java:128)
        at
org.jamon.eclipse.ProjectClassLoader.addDependencyClasspath(ProjectClassLoader.java:152)
        at
org.jamon.eclipse.ProjectClassLoader.addDependenciesClasspath(ProjectClassLoader.java:160)
        at
org.jamon.eclipse.ProjectClassLoader.classpathUrlsForProject(ProjectClassLoader.java:133)
        at
org.jamon.eclipse.ProjectClassLoader.addDependencyClasspath(ProjectClassLoader.java:152)
        at
org.jamon.eclipse.ProjectClassLoader.addDependenciesClasspath(ProjectClassLoader.java:160)
        at
org.jamon.eclipse.ProjectClassLoader.classpathUrlsForProject(ProjectClassLoader.java:133)
        at
org.jamon.eclipse.ProjectClassLoader.classpathUrlArray(ProjectClassLoader.java:114)
        at
org.jamon.eclipse.ProjectClassLoader.<init>(ProjectClassLoader.java:29)
        at
org.jamon.eclipse.TemplateBuilder$BuildVisitor.<init>(TemplateBuilder.java:220)
        at
org.jamon.eclipse.TemplateBuilder.incrementalBuild(TemplateBuilder.java:186)
        - locked <0x00000000e28129c0> (a org.jamon.eclipse.TemplateBuilder)
        at org.jamon.eclipse.TemplateBuilder.build(TemplateBuilder.java:124)

Re: [Jamon-hackers] Support for jamon.properties from the classpath

[Ian R. <ian...@gm...>]

(adding jamon-hackers back to the recipient list; it looks like I
accidentally did a reply instead of reply-all several messages back)

You asked how much value there is in offering a default set of
jamon.properties. At this point, we have feature requests for:

   - aliases (https://sourceforge.net/p/jamon/feature-requests/7/)
   - defaultEncoding (https://sourceforge.net/p/jamon/feature-requests/8/)
   (this is not currently a jamon property, but probably should be)
   - contextType (same as defaultEncoding)

The only property not currently requested is emitMode, but it doesn't to me
seem unreasonable that one might want to have a default setting for that as
well.

The next question is whether it would be appropriate to set these via a
jar. contextType is the clearest use case for this, since if you depend on
a jar with templates expecting a certain context site, you likely need to
use the same one (or a subtype). As for the others, while the jar isn't
necessarily a "natural" choice, it doesn't feel like an "unnatural" choice
either, nor does it seem completely out of step with the java ecosystem: an
annotation processor on the classpath can impact compilation of source
files, including generation of errors.

The big issue I have with the other options that have been put forth is
that I'm not seeing any easy way to set up a standard configuration that
can be easily applied to a project without copy-and-pasting the whole
configuration. But while copy-and-paste is O(n) in the number of
properties, adding a jar is O(1). Worse, to solve this requires a solution
for each build tool we have (currently 4).

You do have a good point about a property value changing out from
underneath you. It would likely be problematic if aliases or
defaultEncoding were to change. To remedy this, template library
maintainers would need to understand that changing existing aliases or the
defaultEncoding in jamon.lib.properties would constitute a backwards
incompatible change. This would be similar to a library maintainer changing
the name of an enum value or method name.

For contextType, it is arguably a good thing that a referenced template
library could change it - if my dependency changes its context type, and I
don't, my build should fail. Setting emitMode as standard policy doesn't
feel like a bad thing; indeed, if an architect decides that it needs to be
tightened up, having it automatically propagate to a number of projects
could be a good thing - it might break the build, but in ways that one
would want it to break.

  - Ian





On Fri, Aug 30, 2013 at 9:16 AM, Jay Sachs <ja...@co...> wrote:

> If we determine that a default set of jamon.properties is useful, I would
> advocate pulling them unambiguously from system properties, e.g.
>
> org.jamon.defaultEncoding=
> org.jamon.defautJamonContext=
> org.jamon.defaultAlias.abc=
> org.jamon.defaultAlias.def=
> org.jamon.defaultAlias.xyz=
>
>
>
>
> On Thu, Aug 29, 2013 at 9:59 AM, Jay Sachs <ja...@co...> wrote:
>
>> I need to back up a minute. The stuff specified in jamon.properties only
>> is applicable to source templates; it's irrelevant in a precompiled
>> template library. Specifying a default encoding in jamon.properties I think
>> we agree is a Good Thing. The question you and I are discussing is: what is
>> the value of offering a "default" set of jamon.properties, and if it's
>> valuable, how should it be specified?
>>
>> Personally, I think the value is pretty low. Whether on a
>> per-template-project basis you need to specify some pom elements or copy
>> your standard jamon.properties in, I think either one is fine. Consider the
>> following: I'm using some classpath-provided jamon.properties (that I get
>> from a specific dependency, say). I write my templates. Now, my dependency
>> changes one or more of the properties. I can think of nothing good
>> happening in general (though I can imagine some alias-changing to achieve a
>> versioning might work, but that should be done via a new template library
>> dependency version, not re-pointing aliases).
>>
>> What's a good use case for not-source-provided jamon.properties?
>>
>>
>> On Thu, Aug 29, 2013 at 9:32 AM, Ian Robertson <ian...@gm...
>> > wrote:
>>
>>> If it's just setting the encoding, then I would agree with you - its
>>> just as easy to specify a property in the build as it is to include a jar.
>>> However, the challenge is when there are a number of properties that one
>>> wishes set in a consistent fashion. For example, at Overstock, they make
>>> significant use of org.jamon.alias.*alaisName* properties, and they
>>> also use jamonContext. If one has a parent pom, then I believe the jamon
>>> configuration can be set to be inherited, but there is to my knowledge no
>>> easy way to share a default configuration in maven between projects not
>>> sharing a common parent pom. Similarly, sharing properties between eclipse
>>> projects is not an easy thing to do.
>>>
>>> I share your concern about the jamon.properties file of a project being
>>> accidentally included in the jar, leading to unnecessary conflicts. There
>>> are a couple of ways we could mitigate this. One would be to use a
>>> different name for properties resources, say jamon.lib.properties. Another
>>> would be a way to specify on a property-by-property basis whether the
>>> property was inheritable; this would likely require supporting a new syntax
>>> - XML seems like a reasonable choice.
>>>
>>> My other concern about a per-tool configuration is that we already have
>>> four tools to support - eclipse, maven, ant and command line. It seems
>>> reasonable that a gradle plugin would be in order as well. I'd much prefer
>>> that we use a solution which is already supported by these tools, rather
>>> than create a new one that needs to be maintained separately in each of
>>> them.
>>>
>>>
>>> On Mon, Aug 26, 2013 at 2:57 PM, Jay Sachs <ja...@co...> wrote:
>>>
>>>> Consider the use case of splitting templates into library "chunks".
>>>> Each library chunk will have a jamon.properties file specifying the default
>>>> encoding. You'll have to be careful not to include those in the built jars,
>>>> or else it ends up ambiguous. And note that for library templates, we don't
>>>> *care* what the encoding *was* of the source template. It's already been
>>>> compiled.
>>>>
>>>> I really think a setting in pom.xml and/or .eclipse/project and/or
>>>> cmdline flag to tool is the way to go here.
>>>>
>>>>
>>>> On Mon, Aug 26, 2013 at 2:45 PM, Ian Robertson <
>>>> ian...@gm...> wrote:
>>>>
>>>>> It appears that currently, the maven plugin creates a classloader from
>>>>> the testclasspath (this is almost certainly wrong - at the very least, only
>>>>> TestJamonMojo should do this, while JamonMojo should use the compile
>>>>> classpath), and passes this to the constructor of JamonProcessor, which
>>>>> passes it via TemplateParserImpl to the constructor of TemplateDescriber.
>>>>> TemplateDescriber currently uses this classloader in its
>>>>> computeTemplateDescription method to look for library templates.
>>>>>
>>>>> The ant task allows specifying the classpath to be used for the
>>>>> classloader. Currently, the commandline tool simply passes its own
>>>>> classloader as the classloader.
>>>>>
>>>>> There is arguably room for improvement with how we let people
>>>>> configure this. However, since we already need to support template
>>>>> libraries, why not use the same mechanism to support a property "library"?
>>>>>
>>>>>
>>>>> On Mon, Aug 26, 2013 at 10:27 AM, Jay Sachs <ja...@co...> wrote:
>>>>>
>>>>>> And that classloader gets configured ... where? pom.xml? eclipse
>>>>>> plugin properties? At that point, you might as well inline the properties
>>>>>> into the build system configuration file (pom element, eclipse project
>>>>>> preference pane, etc).
>>>>>>
>>>>>>
>>>>>> On Mon, Aug 26, 2013 at 12:20 PM, Ian Robertson <
>>>>>> ian...@gm...> wrote:
>>>>>>
>>>>>>> I agree that we shouldn't use the classlaoder responsible for
>>>>>>> loading the jamon processor. But we pass a classloader to jamonprocessor so
>>>>>>> that it can introspect library templates. We could use that same
>>>>>>> classloader for jamon.properties.
>>>>>>>
>>>>>>> (On a related note, I can't find anything in our docs that states
>>>>>>> this, but it is in the code. Probably also ought to fix that...)
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Aug 26, 2013 at 10:17 AM, Jay Sachs <ja...@co...>wrote:
>>>>>>>
>>>>>>>> The problem with the classpath that I see is that it's the
>>>>>>>> classpath run at template translation compilation time, not at java
>>>>>>>> compilation or runtime. I don't think it's a good idea to try and muck with
>>>>>>>> the classpath used to run the maven plugin.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Aug 26, 2013 at 11:59 AM, Ian Robertson <
>>>>>>>> ian...@gm...> wrote:
>>>>>>>>
>>>>>>>>> URLs seem suboptimal to me. They work fine for an aggregator
>>>>>>>>> project, assuming that the user checks out that project, but otherwise,
>>>>>>>>> they won't help. Absolute URLs would require setting up a server to serve
>>>>>>>>> them (or choosing a canonical directory on every user's box).
>>>>>>>>>
>>>>>>>>> It would seem the classpath to use would be the same one we use
>>>>>>>>> for any library templates. Since we are already using this for templates,
>>>>>>>>> using it for jamon.properties seems natural to me.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Aug 26, 2013 at 8:11 AM, Jay Sachs <ja...@co...>wrote:
>>>>>>>>>
>>>>>>>>>> First: I'm coming around to the idea of an "externally" specified
>>>>>>>>>> default jamon.properties.
>>>>>>>>>>
>>>>>>>>>> The classpath idea is nice in that it is already implemented.
>>>>>>>>>> However, whose classpath is it? Don't we really mean "which ClassLoader(s)
>>>>>>>>>> to consult"?
>>>>>>>>>>
>>>>>>>>>> What about something more explicit and inherently unambiguous?
>>>>>>>>>> For instance, a URL argument to the processor which specifies the location
>>>>>>>>>> of the default jamon.properties? An absolute URL is easy; a relative URL
>>>>>>>>>> would be relative to something based on the build system -- in Maven, the
>>>>>>>>>> project root dir, in Eclipse, the Eclipse workspace root?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Aug 26, 2013 at 10:00 AM, Ian Robertson <
>>>>>>>>>> ian...@gm...> wrote:
>>>>>>>>>>
>>>>>>>>>>> It would be nice if jamon could also pick up jamon.properties
>>>>>>>>>>> from the classpath. I know of at least two use cases:
>>>>>>>>>>>
>>>>>>>>>>> 1) electrotype's desire for a default encoding for all projects
>>>>>>>>>>> could be satisfied more elegantly this way
>>>>>>>>>>> 2) When a project using templates is broken up into multiple
>>>>>>>>>>> modules (maven sub projects), it would be nice to not have to copy the
>>>>>>>>>>> jamon.properties to each module. Overstock has this issue.
>>>>>>>>>>>
>>>>>>>>>>> The challenges I can see are:
>>>>>>>>>>> 1) how to merge a classpath jamon.properties with a source dir
>>>>>>>>>>> jamon.properties
>>>>>>>>>>> 2) how to handle multiple instances of jamon.properties on the
>>>>>>>>>>> classpath.
>>>>>>>>>>>
>>>>>>>>>>> To address these, I would propose the following resolution
>>>>>>>>>>> algorithm:
>>>>>>>>>>>
>>>>>>>>>>> When determining the value of property X for a given directory:
>>>>>>>>>>>
>>>>>>>>>>> 1) If there is a source-folder jamon.properties, and it
>>>>>>>>>>> specifies a value for X for the given directoy or any of it's parents, use
>>>>>>>>>>> the value of the fullest matching path. This is as we currently do things.
>>>>>>>>>>> 2) If there is not a value specified in the source-folder
>>>>>>>>>>> jamon.properties, or if no source-folder jamon.properties exists, look on
>>>>>>>>>>> the classpath for all jamon.properties resources.
>>>>>>>>>>> 2a) If none of these specify a value for X for the given
>>>>>>>>>>> directory or any of its parents, then X has no value.
>>>>>>>>>>> 2b) If exactly one of these specifies a value for X for the
>>>>>>>>>>> given directory or any of it's parents, use that value.
>>>>>>>>>>> 2c) If more than one jamon.properties resource specifies a value
>>>>>>>>>>> for X that could apply to the given directory, and the specified values are
>>>>>>>>>>> not all the same, (and again, there is no applicable value for X specified
>>>>>>>>>>> in the source-folder jamon.properties), throw an exception.
>>>>>>>>>>> 2d) conflicts for directories which have no .jamon files should
>>>>>>>>>>> not cause an exception
>>>>>>>>>>>
>>>>>>>>>>> The idea is that in general, a project should have no more than
>>>>>>>>>>> one jamon.properties on the classpath. If there are, its OK, as long as
>>>>>>>>>>> they don't conflict. If they do, then the project must resolve the
>>>>>>>>>>> ambiguity with a source-folder jamon.properties.
>>>>>>>>>>>
>>>>>>>>>>> One possible change would be to only consider it a conflict
>>>>>>>>>>> between multiple jamon.properties resources if there is not winner based on
>>>>>>>>>>> the most-specific path match. However, it seems right to allow the source
>>>>>>>>>>> jamon.properties to always have precedence regardless, even if it specifies
>>>>>>>>>>> a value at the root directory. Allowing classpath jamon.properties to
>>>>>>>>>>> compete on the basis of path-specificity would seem inconsistent.
>>>>>>>>>>>
>>>>>>>>>>> One risk I can see with this is if a build system is currently
>>>>>>>>>>> accidentally including jamon.properties in the jar (this could happen if
>>>>>>>>>>> src/main/java is also being used for jamon.properties). Builds would need
>>>>>>>>>>> to be modified to exclude these from the jar unless otherwise requested.
>>>>>>>>>>> Previously created jars could create a backwards incompatibility. I suspect
>>>>>>>>>>> that this risk is a manageable one, especially since projects that would be
>>>>>>>>>>> impacted by this are likely to also benefit from this feature.
>>>>>>>>>>>
>>>>>>>>>>> Thoughts?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> Introducing Performance Central, a new site from SourceForge and
>>>>>>>>>>> AppDynamics. Performance Central is your source for news,
>>>>>>>>>>> insights,
>>>>>>>>>>> analysis and resources for efficient Application Performance
>>>>>>>>>>> Management.
>>>>>>>>>>> Visit us today!
>>>>>>>>>>>
>>>>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Jamon-hackers mailing list
>>>>>>>>>>> Jam...@li...
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/jamon-hackers
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [Jamon-hackers] Support for jamon.properties from the classpath

[Jay S. <ja...@co...>]

First: I'm coming around to the idea of an "externally" specified default
jamon.properties.

The classpath idea is nice in that it is already implemented. However,
whose classpath is it? Don't we really mean "which ClassLoader(s) to
consult"?

What about something more explicit and inherently unambiguous? For
instance, a URL argument to the processor which specifies the location of
the default jamon.properties? An absolute URL is easy; a relative URL would
be relative to something based on the build system -- in Maven, the project
root dir, in Eclipse, the Eclipse workspace root?


On Mon, Aug 26, 2013 at 10:00 AM, Ian Robertson
<ian...@gm...>wrote:

> It would be nice if jamon could also pick up jamon.properties from the
> classpath. I know of at least two use cases:
>
> 1) electrotype's desire for a default encoding for all projects could be
> satisfied more elegantly this way
> 2) When a project using templates is broken up into multiple modules
> (maven sub projects), it would be nice to not have to copy the
> jamon.properties to each module. Overstock has this issue.
>
> The challenges I can see are:
> 1) how to merge a classpath jamon.properties with a source dir
> jamon.properties
> 2) how to handle multiple instances of jamon.properties on the classpath.
>
> To address these, I would propose the following resolution algorithm:
>
> When determining the value of property X for a given directory:
>
> 1) If there is a source-folder jamon.properties, and it specifies a value
> for X for the given directoy or any of it's parents, use the value of the
> fullest matching path. This is as we currently do things.
> 2) If there is not a value specified in the source-folder
> jamon.properties, or if no source-folder jamon.properties exists, look on
> the classpath for all jamon.properties resources.
> 2a) If none of these specify a value for X for the given directory or any
> of its parents, then X has no value.
> 2b) If exactly one of these specifies a value for X for the given
> directory or any of it's parents, use that value.
> 2c) If more than one jamon.properties resource specifies a value for X
> that could apply to the given directory, and the specified values are not
> all the same, (and again, there is no applicable value for X specified in
> the source-folder jamon.properties), throw an exception.
> 2d) conflicts for directories which have no .jamon files should not cause
> an exception
>
> The idea is that in general, a project should have no more than one
> jamon.properties on the classpath. If there are, its OK, as long as they
> don't conflict. If they do, then the project must resolve the ambiguity
> with a source-folder jamon.properties.
>
> One possible change would be to only consider it a conflict between
> multiple jamon.properties resources if there is not winner based on the
> most-specific path match. However, it seems right to allow the source
> jamon.properties to always have precedence regardless, even if it specifies
> a value at the root directory. Allowing classpath jamon.properties to
> compete on the basis of path-specificity would seem inconsistent.
>
> One risk I can see with this is if a build system is currently
> accidentally including jamon.properties in the jar (this could happen if
> src/main/java is also being used for jamon.properties). Builds would need
> to be modified to exclude these from the jar unless otherwise requested.
> Previously created jars could create a backwards incompatibility. I suspect
> that this risk is a manageable one, especially since projects that would be
> impacted by this are likely to also benefit from this feature.
>
> Thoughts?
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Jamon-hackers mailing list
> Jam...@li...
> https://lists.sourceforge.net/lists/listinfo/jamon-hackers
>
>

[Jamon-hackers] Support for jamon.properties from the classpath

[Ian R. <ian...@gm...>]

It would be nice if jamon could also pick up jamon.properties from the
classpath. I know of at least two use cases:

1) electrotype's desire for a default encoding for all projects could be
satisfied more elegantly this way
2) When a project using templates is broken up into multiple modules (maven
sub projects), it would be nice to not have to copy the jamon.properties to
each module. Overstock has this issue.

The challenges I can see are:
1) how to merge a classpath jamon.properties with a source dir
jamon.properties
2) how to handle multiple instances of jamon.properties on the classpath.

To address these, I would propose the following resolution algorithm:

When determining the value of property X for a given directory:

1) If there is a source-folder jamon.properties, and it specifies a value
for X for the given directoy or any of it's parents, use the value of the
fullest matching path. This is as we currently do things.
2) If there is not a value specified in the source-folder jamon.properties,
or if no source-folder jamon.properties exists, look on the classpath for
all jamon.properties resources.
2a) If none of these specify a value for X for the given directory or any
of its parents, then X has no value.
2b) If exactly one of these specifies a value for X for the given directory
or any of it's parents, use that value.
2c) If more than one jamon.properties resource specifies a value for X that
could apply to the given directory, and the specified values are not all
the same, (and again, there is no applicable value for X specified in the
source-folder jamon.properties), throw an exception.
2d) conflicts for directories which have no .jamon files should not cause
an exception

The idea is that in general, a project should have no more than one
jamon.properties on the classpath. If there are, its OK, as long as they
don't conflict. If they do, then the project must resolve the ambiguity
with a source-folder jamon.properties.

One possible change would be to only consider it a conflict between
multiple jamon.properties resources if there is not winner based on the
most-specific path match. However, it seems right to allow the source
jamon.properties to always have precedence regardless, even if it specifies
a value at the root directory. Allowing classpath jamon.properties to
compete on the basis of path-specificity would seem inconsistent.

One risk I can see with this is if a build system is currently accidentally
including jamon.properties in the jar (this could happen if src/main/java
is also being used for jamon.properties). Builds would need to be modified
to exclude these from the jar unless otherwise requested. Previously
created jars could create a backwards incompatibility. I suspect that this
risk is a manageable one, especially since projects that would be impacted
by this are likely to also benefit from this feature.

Thoughts?

[Jamon-hackers] [ jamon-Bugs-3156388 ] Improve Maven Plugin so only changed files are compiled

[SourceForge.net <no...@so...>]

Bugs item #3156388, was opened at 2011-01-12 07:51
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3156388&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Maven plugins
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matt Raible (mraible)
Assigned to: Ian Robertson (iroberts)
Summary: Improve Maven Plugin so only changed files are compiled

Initial Comment:
Currently, all Jamon templates are re-generated when running "mvn compile". It'd be great if only changed templates were re-generated, much like the maven-compiler-plugin. The attached patch includes this enhancement.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2013-04-16 22:21

Message:
ucdnWL  <a href="http://nhsqaycwfqjw.com/">nhsqaycwfqjw</a>,
[url=http://wkxlsedsawtm.com/]wkxlsedsawtm[/url],
[link=http://znzhbkeqcjzd.com/]znzhbkeqcjzd[/link],
http://pgjlqtkjewkc.com/

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3156388&group_id=138569

[Jamon-hackers] [ jamon-Bugs-3156388 ] Improve Maven Plugin so only changed files are compiled

[SourceForge.net <no...@so...>]

Bugs item #3156388, was opened at 2011-01-12 07:51
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3156388&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Maven plugins
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matt Raible (mraible)
Assigned to: Ian Robertson (iroberts)
Summary: Improve Maven Plugin so only changed files are compiled

Initial Comment:
Currently, all Jamon templates are re-generated when running "mvn compile". It'd be great if only changed templates were re-generated, much like the maven-compiler-plugin. The attached patch includes this enhancement.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2013-02-12 12:45

Message:
hFH4la  <a href="http://louxyujvdlfm.com/">louxyujvdlfm</a>,
[url=http://paicegqmezmj.com/]paicegqmezmj[/url],
[link=http://cpiwbxrqhvyj.com/]cpiwbxrqhvyj[/link],
http://xoauniqxrkiy.com/

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3156388&group_id=138569

[Jamon-hackers] [ jamon-Bugs-3565029 ] <%LITERAL> syntax not documented

[SourceForge.net <no...@so...>]

Bugs item #3565029, was opened at 2012-09-05 09:16
Message generated for change (Comment added) made by iroberts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3565029&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Ian Robertson (iroberts)
>Assigned to: Ian Robertson (iroberts)
Summary: <%LITERAL> syntax not documented

Initial Comment:
It appears we do not document the <%LITERAL> syntax anywhere.

----------------------------------------------------------------------

>Comment By: Ian Robertson (iroberts)
Date: 2012-09-05 14:12

Message:
Docs have been fixed and updated on www.jamon.org.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3565029&group_id=138569

[Jamon-hackers] [ jamon-Bugs-3565029 ] <%LITERAL> syntax not documented

[SourceForge.net <no...@so...>]

Bugs item #3565029, was opened at 2012-09-05 09:16
Message generated for change (Tracker Item Submitted) made by iroberts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3565029&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ian Robertson (iroberts)
Assigned to: Nobody/Anonymous (nobody)
Summary: <%LITERAL> syntax not documented

Initial Comment:
It appears we do not document the <%LITERAL> syntax anywhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3565029&group_id=138569

[Jamon-hackers] Proposed addition

[Ian R. <ian...@gm...>]

Jamon <%method>s are great for providing overridable behavior in a parent
template, but they are limited to content. Sometimes, I want to have data
in my parent template that can be overridden in a child template. There is
a mechanism for doing this in Jamon, but it's clunk. For example, in the
jamon doc project, _Base.jamon contains:

<%class>
  ....
  protected abstract Section currentSection();
</%class>

Then in, for example, Changes.jamon, we have:

<%class>
  @Override protected Section currentSection() { return Section.NEWS; }
</%class>

I'm thinking that this is perhaps more verbose than it needs to be, and is
not friendly to non-java programmers who might want to edit a template. I'm
envisioning something like

Parent.jamon:
<%absparam currentSection>Section currentSection</%absParam>
or
<%param currentSection>Section currentSection = Section.DEFAULT</%param>

Child.jamon
<%overrideParam currentSection>Section.NEWS</%overrideParam>

These would translate under the covers to final variables set on
construction, much like args. The difference is that rather than the
arguments provided from the template caller, they are specified in the
template itself.

The syntax and names above are just a first stab. I've chosen the name
param to evoke the notion of a parameterized template. I've also chosen to
declare each parameter separately (like we do methods), rather than all
together (like we do args). I don't feel strongly about any of these
choices.

Of course, one way to mimic this behavior today is with arguments having
default values. However, this is suboptimal in at least two ways. One is
that there is no way to declare an argument as "abstract" - either it has a
default value, or it doesn't. The second deficiency is that ideally, these
parameters shouldn't be exposed to the template caller at all; its an
internal implementation detail.

Thinking about it briefly, I'm not seeing too many deep difficulties with
this. We would need to track the names of parameters along with the names
of args to ensure there aren't any conflicts between the two. Other than
declaring parameters in annotation form under the @Template annotation, the
proxy would be unaffected by parameters. In particular, calling templates
would be unchanged by this.

Thoughts?

  - Ian

[Jamon-hackers] [ jamon-Bugs-3486563 ] Eclipse plugin crashed when a whitespace is eclipse'spath

[SourceForge.net <no...@so...>]

Bugs item #3486563, was opened at 2012-02-10 07:19
Message generated for change (Comment added) made by yvesdm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3486563&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Eclipse plugins
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Yvesdm (yvesdm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Eclipse plugin crashed when a whitespace is eclipse'spath

Initial Comment:
My eclipse 3.7 is installed under program files.
When a space is present in the path, The plugin crash with the following stack trace :

java.net.URISyntaxException: Illegal character in path at index 16: file:/C:/Program Files/eclipse 3.7/plugins/org.jamon.processor_2.4.1/jamon-processor-2.4.1.jar
	at java.net.URI$Parser.fail(Unknown Source)
	at java.net.URI$Parser.checkChars(Unknown Source)
	at java.net.URI$Parser.parseHierarchical(Unknown Source)
	at java.net.URI$Parser.parse(Unknown Source)
	at java.net.URI.<init>(Unknown Source)
	at java.net.URL.toURI(Unknown Source)
	at org.jamon.eclipse.ProcessorJarLocations.getPluginProcessorJar(ProcessorJarLocations.java:56)
	at org.jamon.eclipse.ProcessorJarLocations.jarFile(ProcessorJarLocations.java:69)
	at org.jamon.eclipse.TemplateBuilder$BuildVisitor.<init>(TemplateBuilder.java:222)
	at org.jamon.eclipse.TemplateBuilder.incrementalBuild(TemplateBuilder.java:186)
	at org.jamon.eclipse.TemplateBuilder.build(TemplateBuilder.java:124)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)

----------------------------------------------------------------------

>Comment By: Yvesdm (yvesdm)
Date: 2012-02-10 07:30

Message:
This may be helpfull to fix it :
http://weblogs.java.net/blog/kohsuke/archive/2007/04/how_to_convert.html

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3486563&group_id=138569

[Jamon-hackers] [ jamon-Bugs-3486563 ] Eclipse plugin crashed when a whitespace is eclipse'spath

[SourceForge.net <no...@so...>]

Bugs item #3486563, was opened at 2012-02-10 07:19
Message generated for change (Tracker Item Submitted) made by yvesdm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3486563&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Eclipse plugins
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Yvesdm (yvesdm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Eclipse plugin crashed when a whitespace is eclipse'spath

Initial Comment:
My eclipse 3.7 is installed under program files.
When a space is present in the path, The plugin crash with the following stack trace :

java.net.URISyntaxException: Illegal character in path at index 16: file:/C:/Program Files/eclipse 3.7/plugins/org.jamon.processor_2.4.1/jamon-processor-2.4.1.jar
	at java.net.URI$Parser.fail(Unknown Source)
	at java.net.URI$Parser.checkChars(Unknown Source)
	at java.net.URI$Parser.parseHierarchical(Unknown Source)
	at java.net.URI$Parser.parse(Unknown Source)
	at java.net.URI.<init>(Unknown Source)
	at java.net.URL.toURI(Unknown Source)
	at org.jamon.eclipse.ProcessorJarLocations.getPluginProcessorJar(ProcessorJarLocations.java:56)
	at org.jamon.eclipse.ProcessorJarLocations.jarFile(ProcessorJarLocations.java:69)
	at org.jamon.eclipse.TemplateBuilder$BuildVisitor.<init>(TemplateBuilder.java:222)
	at org.jamon.eclipse.TemplateBuilder.incrementalBuild(TemplateBuilder.java:186)
	at org.jamon.eclipse.TemplateBuilder.build(TemplateBuilder.java:124)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3486563&group_id=138569

[Jamon-hackers] [ jamon-Bugs-3462561 ] Template replacements do not receive context.

[SourceForge.net <no...@so...>]

Bugs item #3462561, was opened at 2011-12-19 15:51
Message generated for change (Comment added) made by iroberts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3462561&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Ian Robertson (iroberts)
Assigned to: Ian Robertson (iroberts)
Summary: Template replacements do not receive context.

Initial Comment:
When a template is replaced, the template arguments are passed along, but the context is not.

----------------------------------------------------------------------

>Comment By: Ian Robertson (iroberts)
Date: 2011-12-20 17:35

Message:
Fixed in jamon-processor-2.4.1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3462561&group_id=138569

[Jamon-hackers] [ jamon-Bugs-3462561 ] Template replacements do not receive context.

[SourceForge.net <no...@so...>]

Bugs item #3462561, was opened at 2011-12-19 15:51
Message generated for change (Tracker Item Submitted) made by iroberts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3462561&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ian Robertson (iroberts)
Assigned to: Ian Robertson (iroberts)
Summary: Template replacements do not receive context.

Initial Comment:
When a template is replaced, the template arguments are passed along, but the context is not.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3462561&group_id=138569

[Jamon-hackers] [ jamon-Bugs-3253413 ] jamon-maven-plugin 2.3.3/2.3.4 source scanning not working

[SourceForge.net <no...@so...>]

Bugs item #3253413, was opened at 2011-03-28 11:21
Message generated for change (Comment added) made by iroberts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3253413&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Maven plugins
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jay Sachs (jaysachs)
Summary: jamon-maven-plugin 2.3.3/2.3.4 source scanning not working 

Initial Comment:
Jamon-maven-plugin fails to find the jamon template files created directly under ${project.basedir}/src/main/jamon directory, while this directory is explicitly set as templateSourceDir in pom.xml.

I think scanning works well only if a directory is created under the src/main/jamon directory. I have attached a proposed patch, which modifies the plugin to really scan the configured source directory without unnecessary (as I believe) path "tricks".

----------------------------------------------------------------------

>Comment By: Ian Robertson (iroberts)
Date: 2011-12-01 12:44

Message:
Fixed in 2.4.0

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3253413&group_id=138569

[Jamon-hackers] [ jamon-Bugs-1862302 ] Jamon prefs show up in feature properties page

[SourceForge.net <no...@so...>]

Bugs item #1862302, was opened at 2008-01-02 08:41
Message generated for change (Comment added) made by iroberts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=1862302&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Eclipse plugins
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 6
Private: No
Submitted By: Ian Robertson (iroberts)
Assigned to: Ian Robertson (iroberts)
Summary: Jamon prefs show up in feature properties page

Initial Comment:
Go to Help->Software Updates->Manage Configuration, pick any feature, and click "Show properties".  The dialog that opens lists five sections: Copywrite, General information, Jamon, License Agreement, and Status.  Jamon should not be there.

----------------------------------------------------------------------

>Comment By: Ian Robertson (iroberts)
Date: 2011-12-01 12:38

Message:
Fixed in 2.3.3

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=1862302&group_id=138569

[Jamon-hackers] [ jamon-Bugs-2807733 ] Prevent recursove calls

[SourceForge.net <no...@so...>]

Bugs item #2807733, was opened at 2009-06-17 07:38
Message generated for change (Comment added) made by iroberts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=2807733&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Eclipse plugins
Group: None
>Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Prevent recursove calls

Initial Comment:
jamon eclipse plugin seems to blow a stack trace while trying to build up classpaths.
Attached is a work around patch, but may not be the ideal solution. It got me past the issue
trunk/eclipse/uiPlugin/src/org/jamon/eclipse/ProjectClassLoader.java 

...
  at org.jamon.eclipse.ProjectClassLoader.addDependenciesClasspath(ProjectClassLoader.java:161)
  at org.jamon.eclipse.ProjectClassLoader.classpathUrlsForProject(ProjectClassLoader.java:134)
  at org.jamon.eclipse.ProjectClassLoader.addDependencyClasspath(ProjectClassLoader.java:153)
  at org.jamon.eclipse.ProjectClassLoader.addDependenciesClasspath(ProjectClassLoader.java:161)
  at org.jamon.eclipse.ProjectClassLoader.classpathUrlsForProject(ProjectClassLoader.java:134)
  at org.jamon.eclipse.ProjectClassLoader.addDependencyClasspath(ProjectClassLoader.java:153)
  at org.jamon.eclipse.ProjectClassLoader.addDependenciesClasspath(ProjectClassLoader.java:161)
  at org.jamon.eclipse.ProjectClassLoader.classpathUrlsForProject(ProjectClassLoader.java:134)
  at org.jamon.eclipse.ProjectClassLoader.addDependencyClasspath(ProjectClassLoader.java:153)
  at org.jamon.eclipse.ProjectClassLoader.addDependenciesClasspath(ProjectClassLoader.java:161)


----------------------------------------------------------------------

>Comment By: Ian Robertson (iroberts)
Date: 2011-12-01 12:18

Message:
I still don't understand how this comes about, but I can attest that it
indeed can happen.

----------------------------------------------------------------------

Comment By: Ian Robertson (iroberts)
Date: 2009-07-05 10:23

Message:
I work with the developer who posted this.  We attempted to reproduce, but
were unable to; the problem vanished on his box as well after he upgraded
to Eclipse 3.5.  Notably, he was using maven's eclipse:eclipse goal, so
it's conceivable that this created some oddities.  In any event, closing as
"works for me", since there does not appear to be a "could not reproduce"
option (http://xkcd.com/583/).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-06-20 08:37

Message:
Interesting. Wouldn't you have other issues with cyclical project
dependencies anyway?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=2807733&group_id=138569

[Jamon-hackers] [ jamon-Bugs-3445590 ] Use maven-bundle-plugin to generate jamon-processor-plugin

[SourceForge.net <no...@so...>]

Bugs item #3445590, was opened at 2011-11-29 14:44
Message generated for change (Tracker Item Submitted) made by iroberts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3445590&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Eclipse plugins
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ian Robertson (iroberts)
Assigned to: Ian Robertson (iroberts)
Summary: Use maven-bundle-plugin to generate jamon-processor-plugin

Initial Comment:
The maven-bundle-plugin looks like it's designed to do what we are currently achieving with bailing wire and duct tape.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3445590&group_id=138569

[Jamon-hackers] [ jamon-Bugs-3307564 ] Wrong encoding of string constants in Java code blocks

[SourceForge.net <no...@so...>]

Bugs item #3307564, was opened at 2011-05-25 09:18
Message generated for change (Settings changed) made by iroberts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3307564&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Aron Ujvari (ujvari)
Assigned to: Ian Robertson (iroberts)
Summary: Wrong encoding of string constants in Java code blocks

Initial Comment:
Jamon replaces non-ascii characters with question mark (?) in the string constants written into Java code blocks.

Jamon template example:

<%encoding UTF-8>
<%escape #h>
<%args>
    String title = "Cég adatai";
</%args>
<%java>
String x = "céég";
</%java>
<% title %> <% x %> <% "cééég" %>

Output:
C?g adatai c??g c???g

The cause of the problem is in org.jamon.codegen.CodeWriter:

static final String JAVA_SOURCE_ENCODING = "US-ASCII";
...
m_writer = new PrintWriter(new OutputStreamWriter(p_stream, JAVA_SOURCE_ENCODING));

In the constructor the output writer uses fixed us-ascii encoding for the output code generation. While in non-codeblocks non-ascii characters in strings converted into "\\uXXXX" format, in code-block this conversion does not happen.

The best output encoding for the generated code files probably would be the encoding defined in the source file. This way there would be no need for conversion.

----------------------------------------------------------------------

Comment By: Ian Robertson (iroberts)
Date: 2011-07-08 13:28

Message:
As of 2.4.0, generated java files are written using the same encoding as
specified in the template.

----------------------------------------------------------------------

Comment By: Ian Robertson (iroberts)
Date: 2011-06-27 18:11

Message:
This is fixed on trunk; I hope to be cutting a new release sometime this
week.

----------------------------------------------------------------------

Comment By: Ian Robertson (iroberts)
Date: 2011-06-27 13:06

Message:
According to
http://download.oracle.com/javase/6/docs/technotes/tools/solaris/javac.html,
the encoding the compiler uses defaults to "the platform default converter"
unless a -encoding parameter is passed to the compiler.  If we allow
different generated java files to be encoded with different encodings, this
make the compilation stage challenging. 

That said, it seems that while a user could place a burden on themselves
by using inconsistent charsets, it still makes sense to write java files in
the specified encoding, or in the platform default if none is specified.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3307564&group_id=138569

[Jamon-hackers] [ jamon-Bugs-3220885 ] jamon-maven-plugin should not fork a parallel build.

[SourceForge.net <no...@so...>]

Bugs item #3220885, was opened at 2011-03-17 14:39
Message generated for change (Comment added) made by iroberts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3220885&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Maven plugins
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Ian Robertson (iroberts)
Assigned to: Ian Robertson (iroberts)
Summary: jamon-maven-plugin should not fork a parallel build.

Initial Comment:
Currently, JamonMojo has the following annotations:

/**
 * Translates Jamon templates into Java files.
 *
 * @goal translate
 * @phase generate-sources
 * @execute phase="generate-sources"
 * @threadSafe
 * @requiresDependencyResolution runtime
 */

The @execute annotation instructs maven to fork a parallel build to do the template processing in. Really, all we want is the @phase annotation.

An unfortunate side effect of our current approach is that (at least under maven 2.2.1) when running maven release:perform on a multi-module project in which both two submodules both invoke the translate goal, maven will not run the goal in the second module, fearing that it is forking the translate goal while already inside the translate goal.  While clearly a maven bug, it is in our power to avoid tripping it.

----------------------------------------------------------------------

>Comment By: Ian Robertson (iroberts)
Date: 2011-07-08 13:31

Message:
This was fixed in 2.3.4

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3220885&group_id=138569

[Jamon-hackers] [ jamon-Bugs-3300744 ] Constrained type parameters can cause compilation errors

[SourceForge.net <no...@so...>]

Bugs item #3300744, was opened at 2011-05-11 17:04
Message generated for change (Comment added) made by iroberts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3300744&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Ian Robertson (iroberts)
Summary: Constrained type parameters can cause compilation errors

Initial Comment:
When a JamonContext type is defined, constrained type parameters cause a compilation error in the Proxy class for the template. The following template will fail to compile if a JamonContext type is defined:

<foo.jamon>
  <%generic>T extends Comparable<T></%generic>

  <%args>
    T foo;
  </%args>
</foo.jamon>


I think line 510 in this file:
 
http://jamon.svn.sourceforge.net/viewvc/jamon/trunk/jamon/jamon-processor/src/main/java/org/jamon/codegen/ProxyGenerator.java?revision=2339&view=markup
 
Should read:
 
m_writer.print(m_templateUnit.getGenericParams().generateGenericParamsList ());
 
Instead of:
 
m_writer.print(m_templateUnit.getGenericParams().generateGenericsDeclaration());

----------------------------------------------------------------------

>Comment By: Ian Robertson (iroberts)
Date: 2011-07-08 13:29

Message:
This is fixed in release 2.4.0

----------------------------------------------------------------------

Comment By: Ian Robertson (iroberts)
Date: 2011-05-14 20:45

Message:
Fixed on trunk (revision 2738)

----------------------------------------------------------------------

Comment By: Ian Robertson (iroberts)
Date: 2011-05-12 19:09

Message:
Confirmed, with the caveat that this will not manifest in the absence of an
optional argument or jamonContext.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3300744&group_id=138569

[Jamon-hackers] [ jamon-Bugs-3307564 ] Wrong encoding of string constants in Java code blocks

[SourceForge.net <no...@so...>]

Bugs item #3307564, was opened at 2011-05-25 09:18
Message generated for change (Settings changed) made by iroberts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3307564&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Aron Ujvari (ujvari)
Assigned to: Ian Robertson (iroberts)
Summary: Wrong encoding of string constants in Java code blocks

Initial Comment:
Jamon replaces non-ascii characters with question mark (?) in the string constants written into Java code blocks.

Jamon template example:

<%encoding UTF-8>
<%escape #h>
<%args>
    String title = "Cég adatai";
</%args>
<%java>
String x = "céég";
</%java>
<% title %> <% x %> <% "cééég" %>

Output:
C?g adatai c??g c???g

The cause of the problem is in org.jamon.codegen.CodeWriter:

static final String JAVA_SOURCE_ENCODING = "US-ASCII";
...
m_writer = new PrintWriter(new OutputStreamWriter(p_stream, JAVA_SOURCE_ENCODING));

In the constructor the output writer uses fixed us-ascii encoding for the output code generation. While in non-codeblocks non-ascii characters in strings converted into "\\uXXXX" format, in code-block this conversion does not happen.

The best output encoding for the generated code files probably would be the encoding defined in the source file. This way there would be no need for conversion.

----------------------------------------------------------------------

>Comment By: Ian Robertson (iroberts)
Date: 2011-07-08 13:28

Message:
As of 2.4.0, generated java files are written using the same encoding as
specified in the template.

----------------------------------------------------------------------

Comment By: Ian Robertson (iroberts)
Date: 2011-06-27 18:11

Message:
This is fixed on trunk; I hope to be cutting a new release sometime this
week.

----------------------------------------------------------------------

Comment By: Ian Robertson (iroberts)
Date: 2011-06-27 13:06

Message:
According to
http://download.oracle.com/javase/6/docs/technotes/tools/solaris/javac.html,
the encoding the compiler uses defaults to "the platform default converter"
unless a -encoding parameter is passed to the compiler.  If we allow
different generated java files to be encoded with different encodings, this
make the compilation stage challenging. 

That said, it seems that while a user could place a burden on themselves
by using inconsistent charsets, it still makes sense to write java files in
the specified encoding, or in the platform default if none is specified.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3307564&group_id=138569

[Jamon-hackers] [ jamon-Bugs-3307564 ] Wrong encoding of string constants in Java code blocks

[SourceForge.net <no...@so...>]

Bugs item #3307564, was opened at 2011-05-25 09:18
Message generated for change (Comment added) made by iroberts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3307564&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Aron Ujvari (ujvari)
>Assigned to: Ian Robertson (iroberts)
Summary: Wrong encoding of string constants in Java code blocks

Initial Comment:
Jamon replaces non-ascii characters with question mark (?) in the string constants written into Java code blocks.

Jamon template example:

<%encoding UTF-8>
<%escape #h>
<%args>
    String title = "Cég adatai";
</%args>
<%java>
String x = "céég";
</%java>
<% title %> <% x %> <% "cééég" %>

Output:
C?g adatai c??g c???g

The cause of the problem is in org.jamon.codegen.CodeWriter:

static final String JAVA_SOURCE_ENCODING = "US-ASCII";
...
m_writer = new PrintWriter(new OutputStreamWriter(p_stream, JAVA_SOURCE_ENCODING));

In the constructor the output writer uses fixed us-ascii encoding for the output code generation. While in non-codeblocks non-ascii characters in strings converted into "\\uXXXX" format, in code-block this conversion does not happen.

The best output encoding for the generated code files probably would be the encoding defined in the source file. This way there would be no need for conversion.

----------------------------------------------------------------------

>Comment By: Ian Robertson (iroberts)
Date: 2011-06-27 18:11

Message:
This is fixed on trunk; I hope to be cutting a new release sometime this
week.

----------------------------------------------------------------------

Comment By: Ian Robertson (iroberts)
Date: 2011-06-27 13:06

Message:
According to
http://download.oracle.com/javase/6/docs/technotes/tools/solaris/javac.html,
the encoding the compiler uses defaults to "the platform default converter"
unless a -encoding parameter is passed to the compiler.  If we allow
different generated java files to be encoded with different encodings, this
make the compilation stage challenging. 

That said, it seems that while a user could place a burden on themselves
by using inconsistent charsets, it still makes sense to write java files in
the specified encoding, or in the platform default if none is specified.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3307564&group_id=138569

[Jamon-hackers] [ jamon-Bugs-3307564 ] Wrong encoding of string constants in Java code blocks

[SourceForge.net <no...@so...>]

Bugs item #3307564, was opened at 2011-05-25 09:18
Message generated for change (Comment added) made by iroberts
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3307564&group_id=138569

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Aron Ujvari (ujvari)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong encoding of string constants in Java code blocks

Initial Comment:
Jamon replaces non-ascii characters with question mark (?) in the string constants written into Java code blocks.

Jamon template example:

<%encoding UTF-8>
<%escape #h>
<%args>
    String title = "Cég adatai";
</%args>
<%java>
String x = "céég";
</%java>
<% title %> <% x %> <% "cééég" %>

Output:
C?g adatai c??g c???g

The cause of the problem is in org.jamon.codegen.CodeWriter:

static final String JAVA_SOURCE_ENCODING = "US-ASCII";
...
m_writer = new PrintWriter(new OutputStreamWriter(p_stream, JAVA_SOURCE_ENCODING));

In the constructor the output writer uses fixed us-ascii encoding for the output code generation. While in non-codeblocks non-ascii characters in strings converted into "\\uXXXX" format, in code-block this conversion does not happen.

The best output encoding for the generated code files probably would be the encoding defined in the source file. This way there would be no need for conversion.

----------------------------------------------------------------------

>Comment By: Ian Robertson (iroberts)
Date: 2011-06-27 13:06

Message:
According to
http://download.oracle.com/javase/6/docs/technotes/tools/solaris/javac.html,
the encoding the compiler uses defaults to "the platform default converter"
unless a -encoding parameter is passed to the compiler.  If we allow
different generated java files to be encoded with different encodings, this
make the compilation stage challenging. 

That said, it seems that while a user could place a burden on themselves
by using inconsistent charsets, it still makes sense to write java files in
the specified encoding, or in the platform default if none is specified.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=741043&aid=3307564&group_id=138569

Re: [Jamon-hackers] Removing java-1.5 support

[Jay S. <ja...@ja...>]

A bit late, since it's already in, but this sounds good.

-j

On Jun 16, 2011, at 6:34 PM, Ian Robertson wrote:

> Java 1.6 was release in December of 2006. Java 1.5 entered end of life in April 2008 and became de-supported in November of 2009.
> 
> I'm moving Jamon to a java-1.6 project. In particular, this means that @Override annotations will be generated on methods that implement interface methods. In theory, this could be done via a toggle switch, but the set of users who would benefit from this would be small; I think we're at a point where moving forward makes more sense than holding back.
> 
>  - Ian
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev_______________________________________________
> Jamon-hackers mailing list
> Jam...@li...
> https://lists.sourceforge.net/lists/listinfo/jamon-hackers

[Jamon-hackers] Removing java-1.5 support

[Ian R. <ian...@gm...>]

Java 1.6 was release in December of 2006. Java 1.5 entered end of life in
April 2008 and became de-supported in November of 2009.

I'm moving Jamon to a java-1.6 project. In particular, this means that
@Override annotations will be generated on methods that implement interface
methods. In theory, this could be done via a toggle switch, but the set of
users who would benefit from this would be small; I think we're at a point
where moving forward makes more sense than holding back.

  - Ian