Re: same proyects running under java 1.4 and java 1.5
I strongly recommend staying away from profiles (and having multiple
artifacts being produced by one Maven project). Sooner or later it will bit
you. Also, in a true Maven build, you only do one build (including deploying
to the repository) and therefore having different profiles being activated
based on the JDK the build is being done with doesn't fit well (IMHO).
Go with different modules!
/Anders
On Wed, Apr 13, 2011 at 18:31, Jörg Schaible joerg.schai...@gmx.de wrote:
Hi,
Fernando Wermus wrote:
Hi all,
We have a proyect which we need to compile under java 1.4 for some
companies and 1.6 for other companies. The problem is that in java 1.6 we
have a class that implements an interface named ResulSet. Result changes
its methods from 1.4 to 1.6 because jdbc changes. Then we need to have an
implementation of Resulset for java 1.4 and another impl for java 1.6.
What we need is to add to our currents profiles a way to include or
exclude some class in the proyect with the same package and class name.
Is any solution from maven for this problem?
thanks in advance and I hope you have understood our problem.
This is how we did it:
1/ Use two independent version lines i.e. do it like Apache commons dbcp
where version 1.3.x is for JDBC 3 (Java 5 or lower) and version 1.4.x is
for
JDBC 4 (Java 6).
2/ Use comment markers in your Java code, see following snippet:
= % =
/*JDBC4**/
import java.sql.NClob;
import java.sql.RowId;
import java.sql.SQLXML;
//*JDBC4*/
= % =
All types and methods that are only available for JDBC 4 are surrounded
with
those two markers i.e. the code is compilable from your IDE with Java 6 as
usual.
3/ Prepare the POM to modify the source using a profile based on the target
JDK.
The trick is to use the original source that compiles against JDBC 4 and
filter it (resp. generate new sources) with a regular expression that uses
those two markers to create Java block comments and let the compiler use
the
new sources then.
=== % ===
...
groupIdyour.company/groupId
artifactIdyour.artifact/artifactId
version${version.your.artifact}/version
...
build
sourceDirectory${local.source.directory}/sourceDirectory
/build
...
profiles
profile
idjdk15/id
activation
jdk1.5/jdk!-- JDBC 3 only --
/activation
build
plugins
plugin
groupIdyour.company/groupId
artifactIdregexp-plugin/artifactId
executions
execution
idfilter-jdbc4/id
phasegenerate-sources/phase
goals
goalperform/goal
/goals
/execution
/executions
configuration
regExpFilter
sourceDir${basedir}/src/main/java/sourceDir
targetDir${basedir}/target/generated-
sources/java/targetDir
regExps
regExp
search/\*JDBC4\*\*//search
replace/*JDBC4/replace
/regExp
regExp
search//\*JDBC4\*//search
replaceJDBC4*//replace
/regExp
/regExps
/regExpFilter
/configuration
/plugin
/plugins
/build
properties
local.source.directorytarget/generated-
sources/java/local.source.directory
/properties
/profile
/profiles
...
properties
local.source.directorysrc/main/java/local.source.directory
/properties
=== % ===
The property version.your.artifact is defined in the parent and the
artifact is also declared there in a depMgmt section:
=== % ===
...
dependencyManagement
dependencies
dependency
groupIdyour.company/groupId
artifactIdyour.artifact/artifactId
version${version.your.artifact}/version
/dependency
/dependencies
/dependencyManagement
...
profiles
profile
idjdk15/id
activation
jdk1.5/jdk
/activation
properties
version.your.artifact1.6.0-SNAPSHOT/version.your.artifact
/properties
/profile
/profiles
...
properties
version.your.artifact1.5.0-SNAPSHOT/version.your.artifact
/properties
=== % ===
Now, the plugin we use for the regexp fitlering is not publicly available,
but if you look at Apache dbcp, it is done there with an Ant task and you
should be able to to similar with the antrun plugin. I've also seen once
that plexus-utils have capabilities for regexp filtering, but I don't know
if there's any syntax to activate this for standard Maven filtering. OTOH
it
is really easy to write such a simply plugin yourself ;-)
Note, we used the current JDK for profile activation i.e. it depends on the
Java version we use
Re: same proyects running under java 1.4 and java 1.5
Hi Anders, Anders Hammar wrote: I strongly recommend staying away from profiles (and having multiple artifacts being produced by one Maven project). Sooner or later it will bit you. Also, in a true Maven build, you only do one build (including deploying to the repository) and therefore having different profiles being activated based on the JDK the build is being done with doesn't fit well (IMHO). this is the whole point: You don't have different dependecies, but different version numbers, therefore the profiles don't harm here. In the end it is not different of specifying a version in the depMgmt section to select a specific version. Go with different modules! In this special case, I cannot recommend it. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: same proyects running under java 1.4 and java 1.5
How are you executing one build run that produces both artifacts? Are you really deploying to a repository? I can't see how that would work, but I could be missing something. /Anders On Thu, Apr 14, 2011 at 12:00, Jörg Schaible joerg.schai...@scalaris.comwrote: Hi Anders, Anders Hammar wrote: I strongly recommend staying away from profiles (and having multiple artifacts being produced by one Maven project). Sooner or later it will bit you. Also, in a true Maven build, you only do one build (including deploying to the repository) and therefore having different profiles being activated based on the JDK the build is being done with doesn't fit well (IMHO). this is the whole point: You don't have different dependecies, but different version numbers, therefore the profiles don't harm here. In the end it is not different of specifying a version in the depMgmt section to select a specific version. Go with different modules! In this special case, I cannot recommend it. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: same proyects running under java 1.4 and java 1.5
Interesting solution. thanks! I will consult
2011/4/13 Jörg Schaible joerg.schai...@gmx.de
Hi,
Fernando Wermus wrote:
Hi all,
We have a proyect which we need to compile under java 1.4 for some
companies and 1.6 for other companies. The problem is that in java 1.6 we
have a class that implements an interface named ResulSet. Result changes
its methods from 1.4 to 1.6 because jdbc changes. Then we need to have an
implementation of Resulset for java 1.4 and another impl for java 1.6.
What we need is to add to our currents profiles a way to include or
exclude some class in the proyect with the same package and class name.
Is any solution from maven for this problem?
thanks in advance and I hope you have understood our problem.
This is how we did it:
1/ Use two independent version lines i.e. do it like Apache commons dbcp
where version 1.3.x is for JDBC 3 (Java 5 or lower) and version 1.4.x is
for
JDBC 4 (Java 6).
2/ Use comment markers in your Java code, see following snippet:
= % =
/*JDBC4**/
import java.sql.NClob;
import java.sql.RowId;
import java.sql.SQLXML;
//*JDBC4*/
= % =
All types and methods that are only available for JDBC 4 are surrounded
with
those two markers i.e. the code is compilable from your IDE with Java 6 as
usual.
3/ Prepare the POM to modify the source using a profile based on the target
JDK.
The trick is to use the original source that compiles against JDBC 4 and
filter it (resp. generate new sources) with a regular expression that uses
those two markers to create Java block comments and let the compiler use
the
new sources then.
=== % ===
...
groupIdyour.company/groupId
artifactIdyour.artifact/artifactId
version${version.your.artifact}/version
...
build
sourceDirectory${local.source.directory}/sourceDirectory
/build
...
profiles
profile
idjdk15/id
activation
jdk1.5/jdk!-- JDBC 3 only --
/activation
build
plugins
plugin
groupIdyour.company/groupId
artifactIdregexp-plugin/artifactId
executions
execution
idfilter-jdbc4/id
phasegenerate-sources/phase
goals
goalperform/goal
/goals
/execution
/executions
configuration
regExpFilter
sourceDir${basedir}/src/main/java/sourceDir
targetDir${basedir}/target/generated-
sources/java/targetDir
regExps
regExp
search/\*JDBC4\*\*//search
replace/*JDBC4/replace
/regExp
regExp
search//\*JDBC4\*//search
replaceJDBC4*//replace
/regExp
/regExps
/regExpFilter
/configuration
/plugin
/plugins
/build
properties
local.source.directorytarget/generated-
sources/java/local.source.directory
/properties
/profile
/profiles
...
properties
local.source.directorysrc/main/java/local.source.directory
/properties
=== % ===
The property version.your.artifact is defined in the parent and the
artifact is also declared there in a depMgmt section:
=== % ===
...
dependencyManagement
dependencies
dependency
groupIdyour.company/groupId
artifactIdyour.artifact/artifactId
version${version.your.artifact}/version
/dependency
/dependencies
/dependencyManagement
...
profiles
profile
idjdk15/id
activation
jdk1.5/jdk
/activation
properties
version.your.artifact1.6.0-SNAPSHOT/version.your.artifact
/properties
/profile
/profiles
...
properties
version.your.artifact1.5.0-SNAPSHOT/version.your.artifact
/properties
=== % ===
Now, the plugin we use for the regexp fitlering is not publicly available,
but if you look at Apache dbcp, it is done there with an Ant task and you
should be able to to similar with the antrun plugin. I've also seen once
that plexus-utils have capabilities for regexp filtering, but I don't know
if there's any syntax to activate this for standard Maven filtering. OTOH
it
is really easy to write such a simply plugin yourself ;-)
Note, we used the current JDK for profile activation i.e. it depends on the
Java version we use to run Maven itself. This might not be appropriate, you
will have to define different activations then.
Hope this gives you some ideas,
Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: same proyects running under java 1.4 and java 1.5
Hi Anders, Anders Hammar wrote: How are you executing one build run that produces both artifacts? Are you really deploying to a repository? I can't see how that would work, but I could be missing something. Why do you have to? Even for a release you don't have to release the component in both versions *at once* although it can be of advantage to keep the versions in sync. For snapshots it depends on your orgnization. For CI I would actually build two times with a linked build plan, i.e. when the Java 6 version succeeds proceed with a Java 5 setup. See, it is like working on two branches, but with shared code. Since it is only the version that is different, you have even an automated upgrade path. If you Java 5 app is switching to Java 6 you can use the newer branch. It's compile time compatible only, but that does not matter, because the switch from JDBC 3 to JDBC 4 is also not binary compatible. And, yes, I agree that profiles should normally not be used to select different artifacts, it's just for this case where it gets handy without doing harm if you control the version in a depMgmt section anyway for the client project ;-) - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: same proyects running under java 1.4 and java 1.5
You will be trying to deploy the pom twice (once for each build run) which the release repository policy of your Nexus instance will not let you do. Thus, the build will fail (as it should). But you might be using some tooling will less checking... /Anders On Thu, Apr 14, 2011 at 16:15, Jörg Schaible joerg.schai...@scalaris.comwrote: Hi Anders, Anders Hammar wrote: How are you executing one build run that produces both artifacts? Are you really deploying to a repository? I can't see how that would work, but I could be missing something. Why do you have to? Even for a release you don't have to release the component in both versions *at once* although it can be of advantage to keep the versions in sync. For snapshots it depends on your orgnization. For CI I would actually build two times with a linked build plan, i.e. when the Java 6 version succeeds proceed with a Java 5 setup. See, it is like working on two branches, but with shared code. Since it is only the version that is different, you have even an automated upgrade path. If you Java 5 app is switching to Java 6 you can use the newer branch. It's compile time compatible only, but that does not matter, because the switch from JDBC 3 to JDBC 4 is also not binary compatible. And, yes, I agree that profiles should normally not be used to select different artifacts, it's just for this case where it gets handy without doing harm if you control the version in a depMgmt section anyway for the client project ;-) - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: same proyects running under java 1.4 and java 1.5
Hi Anders, Anders Hammar wrote: You will be trying to deploy the pom twice (once for each build run) which the release repository policy of your Nexus instance will not let you do. Thus, the build will fail (as it should). But you might be using some tooling will less checking... No, it has every time a different version. In the example either 1.4.x(- SNAPSHOT) or 1.5.x(-SNAPSHOT). We're not using Nexus though, but again, it's no different from building two different branches. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: same proyects running under java 1.4 and java 1.5
Make the classes into different jars (java 1.4 and 1.6) and add one ore the other as dependencies under different profiles. Em 13-04-2011 15:01, Fernando Wermus escreveu: Hi all, We have a proyect which we need to compile under java 1.4 for some companies and 1.6 for other companies. The problem is that in java 1.6 we have a class that implements an interface named ResulSet. Result changes its methods from 1.4 to 1.6 because jdbc changes. Then we need to have an implementation of Resulset for java 1.4 and another impl for java 1.6. What we need is to add to our currents profiles a way to include or exclude some class in the proyect with the same package and class name. Is any solution from maven for this problem? thanks in advance and I hope you have understood our problem. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: same proyects running under java 1.4 and java 1.5
Alex, I understand your proposal. Do I need to create two proyects for this situation or could I avoid this? 2011/4/13 Alex Lopez alo...@flordeutopia.pt Make the classes into different jars (java 1.4 and 1.6) and add one ore the other as dependencies under different profiles. Em 13-04-2011 15:01, Fernando Wermus escreveu: Hi all, We have a proyect which we need to compile under java 1.4 for some companies and 1.6 for other companies. The problem is that in java 1.6 we have a class that implements an interface named ResulSet. Result changes its methods from 1.4 to 1.6 because jdbc changes. Then we need to have an implementation of Resulset for java 1.4 and another impl for java 1.6. What we need is to add to our currents profiles a way to include or exclude some class in the proyect with the same package and class name. Is any solution from maven for this problem? thanks in advance and I hope you have understood our problem. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: same proyects running under java 1.4 and java 1.5
Yes, the thing is create 2 projects (in fact 3). So you can include same classes/packages in different jars (different projects). And have the 3rd project depend on each of the others depending on the active profile. I don't know how to do it with only one project... Of course there might be plenty of ways ;) Em 13-04-2011 15:44, Fernando Wermus escreveu: Alex, I understand your proposal. Do I need to create two proyects for this situation or could I avoid this? 2011/4/13 Alex Lopezalo...@flordeutopia.pt Make the classes into different jars (java 1.4 and 1.6) and add one ore the other as dependencies under different profiles. Em 13-04-2011 15:01, Fernando Wermus escreveu: Hi all, We have a proyect which we need to compile under java 1.4 for some companies and 1.6 for other companies. The problem is that in java 1.6 we have a class that implements an interface named ResulSet. Result changes its methods from 1.4 to 1.6 because jdbc changes. Then we need to have an implementation of Resulset for java 1.4 and another impl for java 1.6. What we need is to add to our currents profiles a way to include or exclude some class in the proyect with the same package and class name. Is any solution from maven for this problem? thanks in advance and I hope you have understood our problem. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: same proyects running under java 1.4 and java 1.5
Alex, My boss rejects this option. Any idea? 2011/4/13 Alex Lopez alo...@flordeutopia.pt Yes, the thing is create 2 projects (in fact 3). So you can include same classes/packages in different jars (different projects). And have the 3rd project depend on each of the others depending on the active profile. I don't know how to do it with only one project... Of course there might be plenty of ways ;) Em 13-04-2011 15:44, Fernando Wermus escreveu: Alex, I understand your proposal. Do I need to create two proyects for this situation or could I avoid this? 2011/4/13 Alex Lopezalo...@flordeutopia.pt Make the classes into different jars (java 1.4 and 1.6) and add one ore the other as dependencies under different profiles. Em 13-04-2011 15:01, Fernando Wermus escreveu: Hi all, We have a proyect which we need to compile under java 1.4 for some companies and 1.6 for other companies. The problem is that in java 1.6 we have a class that implements an interface named ResulSet. Result changes its methods from 1.4 to 1.6 because jdbc changes. Then we need to have an implementation of Resulset for java 1.4 and another impl for java 1.6. What we need is to add to our currents profiles a way to include or exclude some class in the proyect with the same package and class name. Is any solution from maven for this problem? thanks in advance and I hope you have understood our problem. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: same proyects running under java 1.4 and java 1.5
On 13/04/2011 10:52 AM, Fernando Wermus wrote: Alex, My boss rejects this option. Any idea? Did he give any reason why? Does he have a solution that he would suggest? If you have modules that have different functionality, they are different modules regardless of why the functionality is different. Your 1.5/1.6 stream will diverge more and more from your 1.4 product as time goes on. You might as well get started right. Ron 2011/4/13 Alex Lopezalo...@flordeutopia.pt Yes, the thing is create 2 projects (in fact 3). So you can include same classes/packages in different jars (different projects). And have the 3rd project depend on each of the others depending on the active profile. I don't know how to do it with only one project... Of course there might be plenty of ways ;) Em 13-04-2011 15:44, Fernando Wermus escreveu: Alex, I understand your proposal. Do I need to create two proyects for this situation or could I avoid this? 2011/4/13 Alex Lopezalo...@flordeutopia.pt Make the classes into different jars (java 1.4 and 1.6) and add one ore the other as dependencies under different profiles. Em 13-04-2011 15:01, Fernando Wermus escreveu: Hi all, We have a proyect which we need to compile under java 1.4 for some companies and 1.6 for other companies. The problem is that in java 1.6 we have a class that implements an interface named ResulSet. Result changes its methods from 1.4 to 1.6 because jdbc changes. Then we need to have an implementation of Resulset for java 1.4 and another impl for java 1.6. What we need is to add to our currents profiles a way to include or exclude some class in the proyect with the same package and class name. Is any solution from maven for this problem? thanks in advance and I hope you have understood our problem. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: same proyects running under java 1.4 and java 1.5
Hi,
Fernando Wermus wrote:
Hi all,
We have a proyect which we need to compile under java 1.4 for some
companies and 1.6 for other companies. The problem is that in java 1.6 we
have a class that implements an interface named ResulSet. Result changes
its methods from 1.4 to 1.6 because jdbc changes. Then we need to have an
implementation of Resulset for java 1.4 and another impl for java 1.6.
What we need is to add to our currents profiles a way to include or
exclude some class in the proyect with the same package and class name.
Is any solution from maven for this problem?
thanks in advance and I hope you have understood our problem.
This is how we did it:
1/ Use two independent version lines i.e. do it like Apache commons dbcp
where version 1.3.x is for JDBC 3 (Java 5 or lower) and version 1.4.x is for
JDBC 4 (Java 6).
2/ Use comment markers in your Java code, see following snippet:
= % =
/*JDBC4**/
import java.sql.NClob;
import java.sql.RowId;
import java.sql.SQLXML;
//*JDBC4*/
= % =
All types and methods that are only available for JDBC 4 are surrounded with
those two markers i.e. the code is compilable from your IDE with Java 6 as
usual.
3/ Prepare the POM to modify the source using a profile based on the target
JDK.
The trick is to use the original source that compiles against JDBC 4 and
filter it (resp. generate new sources) with a regular expression that uses
those two markers to create Java block comments and let the compiler use the
new sources then.
=== % ===
...
groupIdyour.company/groupId
artifactIdyour.artifact/artifactId
version${version.your.artifact}/version
...
build
sourceDirectory${local.source.directory}/sourceDirectory
/build
...
profiles
profile
idjdk15/id
activation
jdk1.5/jdk!-- JDBC 3 only --
/activation
build
plugins
plugin
groupIdyour.company/groupId
artifactIdregexp-plugin/artifactId
executions
execution
idfilter-jdbc4/id
phasegenerate-sources/phase
goals
goalperform/goal
/goals
/execution
/executions
configuration
regExpFilter
sourceDir${basedir}/src/main/java/sourceDir
targetDir${basedir}/target/generated-
sources/java/targetDir
regExps
regExp
search/\*JDBC4\*\*//search
replace/*JDBC4/replace
/regExp
regExp
search//\*JDBC4\*//search
replaceJDBC4*//replace
/regExp
/regExps
/regExpFilter
/configuration
/plugin
/plugins
/build
properties
local.source.directorytarget/generated-
sources/java/local.source.directory
/properties
/profile
/profiles
...
properties
local.source.directorysrc/main/java/local.source.directory
/properties
=== % ===
The property version.your.artifact is defined in the parent and the
artifact is also declared there in a depMgmt section:
=== % ===
...
dependencyManagement
dependencies
dependency
groupIdyour.company/groupId
artifactIdyour.artifact/artifactId
version${version.your.artifact}/version
/dependency
/dependencies
/dependencyManagement
...
profiles
profile
idjdk15/id
activation
jdk1.5/jdk
/activation
properties
version.your.artifact1.6.0-SNAPSHOT/version.your.artifact
/properties
/profile
/profiles
...
properties
version.your.artifact1.5.0-SNAPSHOT/version.your.artifact
/properties
=== % ===
Now, the plugin we use for the regexp fitlering is not publicly available,
but if you look at Apache dbcp, it is done there with an Ant task and you
should be able to to similar with the antrun plugin. I've also seen once
that plexus-utils have capabilities for regexp filtering, but I don't know
if there's any syntax to activate this for standard Maven filtering. OTOH it
is really easy to write such a simply plugin yourself ;-)
Note, we used the current JDK for profile activation i.e. it depends on the
Java version we use to run Maven itself. This might not be appropriate, you
will have to define different activations then.
Hope this gives you some ideas,
Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
